Surprisingly the app still compiled, but tried to use the library class definitions instead of my own. I didn't end up using the library, or continuing with the API service.
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.
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.
The only thing to look forward is is ABI stability for Swift, meaning it's a grown up language and we don't need to pack the runtime with every Swift app anymore.
A big reason behind this was to minimize the binary size, which means a much faster download.
Because we used Objective-C and didn't use any third party code, our todo-list app Accomplish is only 289 KB, whereas the most similar competing app (MinimaList) is 8.8 MB and almost all the other competing apps are between 60 and 80 MB each.
It may seem like an unnecessary optimization, but we're hoping a faster download/install experience, along with close attention to detail in other ways, will give our app a competitive edge.
And by the way, "forward thinking" is not something you can be or do for its own sake. Think about it. That doesnt even make sense.