6 ms·

The objective-c classes that are part of this framework are prefixed with NS which is reserved by Apple. I am not sure why they are using this prefix. Maybe the

The objective-c classes that are part of this framework are prefixed with NS which is reserved by Apple. I am not sure why they are using this prefix. Maybe they don't know objective-c very well or they don't care or whatever. I would love to hear a statement from the developer of NSRails what he has to say about that... Are you reading this?

phatbyte 14y ago
I'm with you one this, I don't even know if Apple would approve apps using NS prefix without their consent.
- pkaler 14y ago
  Apple does not inspect your source code when an App is submitted. They only inspect the binary and the metadata of an App.
  - terhechte 14y ago
    Not true, they scan the binary for symbols. I.e. they check for any usage of private api's. I doubt that they will reject an app just because of their usage of NS.. classes, but on the other hand if the NS... class accidentally has the same name of another internal private Apple API, the app will be rejected (Has happened to other developers already).
    - pkaler 14y ago
      You should be stripping your binary of symbols. (-strip-all, -s) I used the word "inspect" carefully. Apple is probably looking for calls to private APIs by looking at the addresses of functions called in your binary with the addresses of private APIs. They are probably looking for method swizzling of Cocoa APIs by looking at the address passed into method_exchangeImplementations, class_replaceMethod, etc. Looking at the symbols within a binary is probably more effort than it is worth and probably isn't going to be very effective.
      - natesm 14y ago
        The names of all of your classes and messages can be found with `strings` anyways, if they did want to reject based on those.
andymoe 14y ago
Yeah this is really bad form. Prefix needs changed for sure. It's a really cool project though! edit: filed an issue here: https://github.com/dingbat/nsrails/issues/4 https://github.com/dingbat/nsrails/issues/4
- 1qaz2wsx3edc 14y ago
  Not only that but this is an abstraction of ActiveRecord at best. This is just the M of the MVC. I strongly dislike it.
  - dhassin 14y ago
    Hi - author here. I'm curious about your opinion, could you elaborate? Edit: maybe you thought NSRails is an attempt to port Rails to iOS? Please see the readme - that's not the purpose of the framework. NSRails just allows iOS to talk to Rails simply and effectively.
dhassin 14y ago
I am reading! Really only one class is really prefixed with "NS" - everything else is prefixed with "NSR" which should solve any potential namespace issues. I did consider this possibility but I think I preferred the elegance of plain NS, and still highly doubt that Apple will release or has any classes named NSRailsModel :) But I do absolutely agree, it's better to be on the cautious side. It's very likely that NSRailsModel will change in the future. See the ticket posted somewhere in this thread for more details, I'd prefer to keep the discussion there.

phatbyte 14y ago

I'm with you one this, I don't even know if Apple would approve apps using NS prefix without their consent.

pkaler 14y ago
Apple does not inspect your source code when an App is submitted. They only inspect the binary and the metadata of an App.
- terhechte 14y ago
  Not true, they scan the binary for symbols. I.e. they check for any usage of private api's. I doubt that they will reject an app just because of their usage of NS.. classes, but on the other hand if the NS... class accidentally has the same name of another internal private Apple API, the app will be rejected (Has happened to other developers already).
  - pkaler 14y ago
    You should be stripping your binary of symbols. (-strip-all, -s) I used the word "inspect" carefully. Apple is probably looking for calls to private APIs by looking at the addresses of functions called in your binary with the addresses of private APIs. They are probably looking for method swizzling of Cocoa APIs by looking at the address passed into method_exchangeImplementations, class_replaceMethod, etc. Looking at the symbols within a binary is probably more effort than it is worth and probably isn't going to be very effective.
    - natesm 14y ago
      The names of all of your classes and messages can be found with `strings` anyways, if they did want to reject based on those.

andymoe 14y ago

Yeah this is really bad form. Prefix needs changed for sure. It's a really cool project though! edit: filed an issue here: https://github.com/dingbat/nsrails/issues/4 https://github.com/dingbat/nsrails/issues/4

1qaz2wsx3edc 14y ago
Not only that but this is an abstraction of ActiveRecord at best. This is just the M of the MVC. I strongly dislike it.
- dhassin 14y ago
  Hi - author here. I'm curious about your opinion, could you elaborate? Edit: maybe you thought NSRails is an attempt to port Rails to iOS? Please see the readme - that's not the purpose of the framework. NSRails just allows iOS to talk to Rails simply and effectively.

dhassin 14y ago

I am reading! Really only one class is really prefixed with "NS" - everything else is prefixed with "NSR" which should solve any potential namespace issues. I did consider this possibility but I think I preferred the elegance of plain NS, and still highly doubt that Apple will release or has any classes named NSRailsModel :) But I do absolutely agree, it's better to be on the cautious side. It's very likely that NSRailsModel will change in the future. See the ticket posted somewhere in this thread for more details, I'd prefer to keep the discussion there.