10 Things Apple Could Do to Make iPhone Development Perfect
I admit, I love developing for iPhone. I’ve been doing it non-stop for over a year, for various clients, full-time and part-time, and most of the annoyances many developers complain about I don’t even notice myself anymore. I don’t desire garbage collection — I can speak retain and release like I do English. I enjoy Objective-C despite its quirks. Etc., etc.
That being said, Apple, if you’re listening, if you just did the following 10 things, I would be in programmer heaven. So, here we go, the Top 10 things Apple could do to make iPhone development perfect!
This is obvious. Everyone wants this. I am a big believer in using little-f frameworks and libraries, but it’s hampered by the excruciating processes required to bring them in. Three20 is great, but what a pain to bring it into a project. Many require upwards of 10 steps! Starting a project is painful due to this. And there is always one little check box or one little include path that you forget to do that takes too much time to figure out. Why should developers be punished for using libraries that greatly increase the utility and reliability of their apps?!
You already support it for Mac. Apple, stop dorking around with gyroscopes and allow Frameworks for iPhone!
Come on, even the Java ME simulators allowed this! You could open up a popup that allowed you to change latitude and longitude. The GPS would detect the change (you didn’t even have to hit OK!) and would place you where you specified. Somewhere in XCode Apple has hardcoded Cupertino, California. Is it so hard to just allow a user to change this for testing purposes?
It’s frustrating in how easy it is to do and how annoying it is for developers. ARGGG!
Automatically Add #import Statements
As a former Java and Flex developer, it was a pleasure to be able to hit a simple key sequence in Eclipse and have imports added automatically. Actually, for Flex, it’s slightly more tricky, you have to hit Control-Space right after the class name to do it, but it’s still a guilty pleasure.
While not trivial, I’d love to see XCode have this feature! If it can syntax color the class names, it can add the imports automatically. I can’t explain how much time this would save! Please, please!
Allow Multiple Simulators for Bluetooth Testing
Apps that support interaction with nearby phones are great fun! While I’ve never had to write one (thankfully), I’ve seen the pain it causes when testing. You can’t run two simulators at once to do so. It’s silly! With simulator support, more apps would support these cool features! Encourage it by allowing a developer to run two separate iPhone Simulators at once and allowing them to connect.
How cool would that be?
Replace The Crappy Unit Testing Framework
The native unit testing framework is an abomination. There is no positive feedback that your tests ran, unless you enjoy reading reams of compilation logs. Anybody who does unit testing knows how many times they’ve hit the situation where all the tests run fine until they realize, OMG, the tests were never actually running!
Also, there is no UI. I want to see a green bar. I want to see how many tests ran. I want to know how long it took. TDD developers expect these things as a baseline! I’ve written a new framework, WiteBox, to replace it and there is also the wonderful GHUnit. I’d love to see one of these be the new native standard someday.
Allow Synthesized Override
This one is subtle. Say, for example, you create some ivars and properties and then you use the @synthesize command to create the setters and getters for you. As is often the case, you may want to write your own setter so that when a value is set you can change some other data or UI to reflect that. So, you write your own setWhatever() method and…
Problem is, you have to then write your own memory management code. If you’ve done iPhone coding for a while, you can write it without thinking. But why should I think? What if we could call “super.setWhatever = ” as if the synthesized method still exists? Or what if I had a syntax like “synthesized.whatever = ” I could call? That would be nice. Then I could focus on the new functionality and not on the setter code that Apple is already capable of auto-generating for me.
As it stands now, specifying copy or retain in your property is completely useless if you write your own setter. That seems wrong.
Pretty please? I’d be so happy.
Prevent Project File Merges #$&^!
OMG, why isn’t this #1? If you’ve ever worked on an iPhone project with even ONE other developer, you likely find yourself doing a manual merge of the project file at least twice a day. It gets scarier with 3 developers, or 4 developers, and so on. Many of you out there go it alone and don’t run into this, but I assure you — it’s a NIGHTMARE. Praying you never have to work with someone else is not a solution.
Apple, change your project file format and do something about this nuisance! Steve, you hearing me??
Native Private Methods
Yes, I know how to use Categories to fake it. No, it isn’t pretty. It’s 2010, Objective-C should allow for *true* private methods. Enough of this “Don’t use the Private API” stuff. PRIVATE METHODS! NOW!
Add Ability to Create Groups as Folders
When you add groups, they don’t create folder structure. This often leads to directories full of inter-mixed content in the project folder. It looks nice in XCode, but it would be nice to have a little more order in the source. The only way to map a group to a folder is to manually create the folder yourself and then drag it into XCode. How about allowing us to create a group and then have a checkbox to create a folder as well?
Add a super Call to loadView Already!
Minor, but obnoxious enough to make this list. loadView() is the recommended place to add UI elements to a UIViewController derived class. Yet, the default template has failed to provide the [super loadView] call for the last year. Add it in. :-)
I can’t count how many times I had the infamous recursive call error occur because I forgot to add [super loadView] myself. Uggg!