What I would like to see at WWDC 2013

As the Apple WWDC 2013 conference approaches, the spotlight has begun shining on the possibilities of what Apple will soon reveal. This year, the major topics revolve around flat UI, anti-skeumorphism, and black and white UI. However, these thoughts are very end-user-centric. What about developers? What will iOS 7 bring to developers?

Well, it is hard to predict these things, but the following is a wish-list of what I really would like to see during the WWDC sessions:

1. Dev Tools: better LLDB documentation. LLDB is really an amazing tool, but it’s a pity it is documented so poorly. The LLDB documentation is unavailable in the Apple Documentation (but you can still find the GDB documentation). It seems that people writing the documentation did not realize Apple deprecated GDB and introduced LLDB. Today, if you want to learn how to use LLDB, you need to go to this website and combine that poor set of examples with an equally poor help command from the console. I learnt LLDB mainly by watching Apple engineers using it, but damn, how can you find out what you can really do with LLDB from the doc? Additionally, not every LLDB command is implemented in the Xcode UI and the most useful commands are only available through the console. So, I would really see a revamp of the Apple documentation for LLDB at the upcoming WWDC.
2. Dev Tools: the ability to attach LLDB to a running app from the terminal. At the moment, you can attach LLDB to a running iOS app only through Xcode. However, there are situations where you need to launch the app on a device and attach LLDB from the Terminal.app, because maybe you don’t have the source code of that application, but you developed a framework that application is using. In this case, attaching LLDB from the terminal and using it to debug your framework would save you a lot of trouble. This feature is really missed and it would be great to have it.
3. Dev Tools: A working merging mechanism to solve NIB and Storyboard conflicts. Why are we still fighting against NIB conflicts in 2013? At Invasivecode, we use NIBs and Storyboards a lot and to reduce the pains at the moment of a merging conflict, we established some internal policies and modify the GIT settings in a certain way to overcome this problem. I would really like to see Xcode solving this issue for us.
4. Dev Tools: live code injection. When you are debugging some real-time rendering algorithm (for example, while rendering a gradient or a path), you absolutely want this feature. It is really annoying to code, compile, look at the result, stop Xcode, modify the source code and compile again to see the new results. I spend hours with this “boring” cycling procedure to make the rendering perfect. So, can we do that while the application is running on a device or the simulator and inject new code at run-time using Xcode? There is a third-party Xcode plugin that already does that, and it would be great to get it from Apple.
5. Dev Tools: live preview. I do a lot of image processing work. There, you usually code the algorithm, run it, save some partial results (usually tons of images), then go to the Organizer and download the data from the iPhone or iPad, unzip the files and load the images in the Preview.app to look at the results. Then, if needed, you change again the source code, and go again through the previous procedure. So, what about showing the partial results directly in Xcode while debugging? The same feature could be used for video processing, graphic rendering and so on.
6. Dev Tools: Xcode plugins. Ok, why did Apple remove this feature from Xcode? For those of you who have never worked with Xcode 3, you should know that you could extend its functionalities by creating and adding plugins. I had some really cool Xcode plugins solving some very specific needs, but when Xcode 4 came out, I lost all of them. Now, since there are some very specific functionalities you want depending on your work, why can’t we build these functionalities by ourselves? I would like to see Xcode plugins again.
7. Dev Tools: custom Interface Builder objects. This was also available in a previous versions of Developer Tools. Say, you always use a toolbar with 3 buttons or some specific tableview custom cell. In Xcode 3 (when Interface Builder was a standalone application), you could create and add this new object to your IB library and re-use it in every new project. This feature disappeared in Xcode 4. So, can we get it back again?
8. Dev Tools: Better integration of the project files with GIT. If you are using the Source Control System integrated in Xcode and you work with other developers, I am sure you got this problem. If you did not correctly set up the .gitignore file, the Xcode project files start to give you a lot of merging problems. Last year, I spoke with a couple of Tools Apple engineers during the WWDC. They told me that the problem would have disappeared with the future Xcode releases. It did not. So, I hope this year, the management of the Xcode project files gets better.
9. Dev Tools: better Certificate and Provisioning Profile management. I have to admit this is improving every year, but it is not perfect yet. We still need to go to the web, login in to the Apple developer portal, generate the digital certificates, download and install them from Xcode. Can we just do everything from Xcode? And can we get a solution to manage multiple identities? This is an issue if you work for different customers and need to create a different identity for each of them. Then, to use the right certificate, you need either to avoid to store your login and password in the keychain or every time you need to change your identity in the keychain.
10. Dev Tools. Instruments flags. Why have the flags been removed from Instruments? Some months ago, I published this post. This really useful feature has unfortunately been removed from Instruments in iOS. Please, give it back.
11. Dev Tools. Bug tracker app. It would be great to have a simple tool to track your bugs. Something similar to Radar. Maybe an OS X Server application, you can install on your machine that stores bug reports created by an Xcode client. That would be fantastic.
12. MapKit. Routes. I think this is one of mine most requested features. It is already available in the Google Map API, but it would be nice to also have it in MapKit. So, given two locations, I would like to be able to get the driving or walking directions between two points and draw them in my app with no need to launch Maps and quit my app. It would be a better user experience.
13. MapKit. Automatic tiling. In the past, we have developed some iOS apps that needed custom map textures on top of a map view. To do it efficiently, you need to tile the usually large texture at different zoom levels and then, load and render only the tiles corresponding to visible region. I think this feature would be useful for many other developers if it was a standard feature of MapKit.
14. MapKit. Annotation views clustering. When you have too many annotation views on the map view, you should cluster these views at lower zoom levels to avoid completely covering the map. This is what Apple taught us during one of the past WWDC. So, why isn’t this feature available for everybody as a standard feature?
15. Networking. Reachability. Why do I need to add the Reachability class to every app I develop when I need to connect to the Internet? This happens mainly for 80% of the iOS apps, right? Can we simply get this feature for free maybe in NSURLConnection?
16. UIKit. UI customization. There are still portions of UIKit you cannot fully customize. For example, just to mention a few: the title of UIBarButtonItem (yes, I know you can do it using a UIButton, but aren’t we trying to write less code?) or the section index of a UITableview.
17. UIKit. State preservation and restoration. These features are very well integrated in Storyboard, but if you are using NIBs, you have to type more code. It would be great to get the same level of integration in the NIB files.
18. Core Animation. Physics engine. To create more dynamic UIs similar to Facebook Home or create effects similar to the scrollview or tableviews bounces, you need to use a physics engine like Box2D or Chipmunk. It would be great to see any of these open source frameworks fully integrated in Core Animation to simulate gravity, collisions, elasticity and compression.
19. AVFoundation. API reorganization. This would be a huge change and I don’t think I will see any of it at the next WWDC, but I like to hope. I use AVFoundation a lot in my work, but I don’t understand why it is such a peculiar framework. I am referring to its design. For example, to switch from the rear iPhone camera to the front one, why do I have to loop on all the available cameras and then, exit the loop when I find the camera I want? Or to render the camera frames on GL context, why do I need to write all that source code. Can we also get an update of the examples? Many of them are still using the manual reference count.
20. iCloud. Well, no comments here. What about deprecating it and starting from the scratch? Instead, can we get a service similar to Parse that allows you to build the functionality in Cocoa and push it to the server?
21. Siri. Public API. I hope this would be the WWDC dedicated to Siri. I would like to see a new API not only in iOS, but also in Mac, so that we can integrate Siri in our applications.
22. MapKit. OS X version. Ok, I know Apple Maps were not really a success last year, but still I think they are much better than Google Maps, because fully integrated in iOS. I think Apple should port MapKit to the Mac and to the web. This will allow us to make uniform user experience applications. Why do I have to use Google Maps on my Mac to find directions or places and then, when I am on the road use the Apple Maps? Apple, let developers build cross-platform location service solutions, and you will see that Google Maps will be forgotten.
23. OpenCL. iOS version. I am tired of using OpenGL to do image processing and you cannot really implement every image algorithm with OpenGL. OpenCL would be the solution. Apple introduced OpenCL for Mac in OS X 10.6 Snow Leopard.
24. PassKit. The reader. This is a piece missed in the chain. We can build applications generating Passes, but we cannot easily build the reader side of that passes. Can we get the 2D barcode reader functionality?
25. Core Image. Custom filters. Well, I think it’s time to get this feature. It is already possible on the Mac to build your own custom Core Image filters. Let developers build custom filters.

We develop iOS and OS X apps and teach iOS (and exclusively iOS) development since 2008. We have not jumped into the multi-platform game yet. However, during the last few months, we are seeing a consistent number of iOS developers starting to work with other mobile platforms searching for new revenues and business models. Apple should stop this migration otherwise this will slowly kill the platform in combination with the smaller competitive advantages. Apple needs to create technologies which will lock developers in the iOS platform (such as Passbook or Siri or Core Bluetooth). These technologies should be easy to integrate and very difficult to replicate on other platforms without the support of Google and Microsoft.

If developers stop to develop the same app for every mobile platform, users will prefer to buy a smartphone providing only the best and most useful apps. This is the issue Microsoft is facing now: the phones are great piece of hardware, but useless because most of the most useful applications are still missing.

I hope Apple will continue to listen to developers.

Geppy