3 ms·

Historically, one of the key dangers with using unprefixed names has been that future system updates add new classes which collide. Testing at dev-time won't fu

Historically, one of the key dangers with using unprefixed names has been that future system updates add new classes which collide. Testing at dev-time won't future-proof you very well.

penpapersw 10y ago
Good point! Just updated the blog post to mention this. Ultimately I don't think it's still too big of an issue. It just means that you may need to rename your classes in the future if an OS update causes a class name collision.
LeoNatan25 10y ago
System should not add unprefixed classes; this is one of the biggest sins a system framework can do, especially one from Apple and its engineers, who are aware of ObjC limitations.
mightykan 10y ago
Somewhat related: In 2010 I implemented a UIView subclass for a simple stylized spinner. In the view controller that contained this spinner, I added two methods to start and stop the spinner. I called them `startSpinner` and `stopSpinner`. Our app was rejected for using “private APIs.” Finding it ridiculous that Apple would use such a common signature internally without any prefixes and actually would check for it in all third-party apps and reject them, we relented and changed our method names. In 2015, at a new job, in a new city and working on an entirely different project, I had to implement another UI spinner. Since I’m a creature of habit, I again named the methods for starting and stopping the spinner: `startSpinner` and `stopSpinner` respectively. This time the project I was working on was an SDK so all of our clients were being rejected for using a private API, named... “startSpinner” and “stopSpinner”. Software is hard.
- aphextron 10y ago
  >Software is hard. More like Apple is extremely arbitrary and ham-handed with their APIs. Cocoa Touch is the most poorly designed framework I have ever dealt with in my programming career. Their insistence on keeping the libraries closed source is absolutely insane, and often leaves you needing to roll something completely custom just to change a color. The lack of a viable native alternative led me to abandon iOS development personally.

Historically, one of the key dangers with using unprefixed names has been that future system updates add new classes which collide. Testing at dev-time won't future-proof you very well.

penpapersw 10y ago

Good point! Just updated the blog post to mention this. Ultimately I don't think it's still too big of an issue. It just means that you may need to rename your classes in the future if an OS update causes a class name collision.

LeoNatan25 10y ago

System should not add unprefixed classes; this is one of the biggest sins a system framework can do, especially one from Apple and its engineers, who are aware of ObjC limitations.

mightykan 10y ago

Somewhat related: In 2010 I implemented a UIView subclass for a simple stylized spinner. In the view controller that contained this spinner, I added two methods to start and stop the spinner. I called them `startSpinner` and `stopSpinner`. Our app was rejected for using “private APIs.” Finding it ridiculous that Apple would use such a common signature internally without any prefixes and actually would check for it in all third-party apps and reject them, we relented and changed our method names. In 2015, at a new job, in a new city and working on an entirely different project, I had to implement another UI spinner. Since I’m a creature of habit, I again named the methods for starting and stopping the spinner: `startSpinner` and `stopSpinner` respectively. This time the project I was working on was an SDK so all of our clients were being rejected for using a private API, named... “startSpinner” and “stopSpinner”. Software is hard.

aphextron 10y ago
>Software is hard. More like Apple is extremely arbitrary and ham-handed with their APIs. Cocoa Touch is the most poorly designed framework I have ever dealt with in my programming career. Their insistence on keeping the libraries closed source is absolutely insane, and often leaves you needing to roll something completely custom just to change a color. The lack of a viable native alternative led me to abandon iOS development personally.