pod2g triggered a lot of chatter on Twitter today by trending #weWantAnOpeniOS in an attempt to get some attention from Apple to open up iOS. I support this idea wholeheartedly. As a tweak developer, my goal is to improve the way I interact with my device to make it even more powerful than Apple ships it out of the box. Right now, the only way to do this is to jailbreak because Apple doesn’t provide the necessary APIs to allow the customizations that I’d like to see on a device. But jailbreaking is flawed in many ways:
- Jailbreaking, by it’s nature, removes many of the security features built into the OS making your device less secure (turns off code signing, for example).
- Jailbreaking requires a lot of work from a lot of smart people to find vulnerabilities so it’s an inherently unstable and unpredictable process.
- Utilizing code swizzling and substrate code injection results in frequent code conflicts - tweaks constantly collide and result in crashes and unintended side effects.
- Since most tweaks need access to undocumented APIs, it’s often difficult to find the right APIs to accomplish a task.
- Since many of the places people want to tweak are not intended to be tweaked, they don’t run in safe, sandboxed processes and a bad piece of code and crash your whole device, not just an app.
Many people look at Android as the “open” mobile solution. Again, depending on your definition of open, that’s true - there are a ton more customization and tweaking APIs available on Android to allow developers to legitimately modify the way the OS works. Additionally, since the OS is developed in Java, some of the risk of system instability due to bad tweak code are removed since Java’s memory management model prevents those types of issues.
So what would I like to see from Apple to make the OS more “open”?
For obvious reason, I’d like to see APIs added to replace the lockscreen on iOS. There are already APIs available in the private frameworks that get you part of the way there. These are the APIs that LockInfo and Cydget leverage to safely coexist on the lockscreen with the music controls, Nike apps, voice recorder and other native OS features that replace the lockscreen. I’d like to see these APIs officially supported and opened up further to support lockscreen customizations.
One problem here is that the lockscreen currently runs in the SpringBoard process which makes customization unstable - bad code in the custom lockscreen could crash the device. But if the lockscreen was moved to a separate process and sort of run as an “app” on the device, the worst that could happen is the lockscreen “crashes” and reopens - the OS can be designed to prevent access to the device until the lockscreen app says so.
Custom Notification Center Widgets
Like it or not, NC is the iOS answer to Android widgets. Working within those constraints, I’d like to see the already-existing BulletinBoard APIs opened up to support fully-compliant widgets on the App Store. Again, if all of Notification Center is moved to a safe process, a faulty widget can’t do anything other than “crash” Notification Center - something the core OS can see and recover from fairly easily.
Core Application Replacements
iOS is in desperate need of a better mail app. App developers have tried to do this, but without native mail APIs that allow the core OS to handle to configuration, fetching and management of mail messages, these apps are limited in what they can do and how truly integrated into the OS they can be. If the currently existing mail APIs are opened up and supported some more, a truly integrated Sparrow or Mailbox can be written and be just as robust as any of the great calendar replacements on the App Store.
In general, the same thing applies to all of the core apps on iOS. At this point, what draws people to iOS is the SDK and the App Store, not the native iOS apps. You can find endless blogs out there with people talking about shoving all of the native iOS apps in the “Crapple” folder and using less featured options like Gmail, Chrome, Google Maps, etc for their standard activities. If Apple properly separated all of their core apps into the frameworks and the UI, than app developers could leverage the same frameworks and build innovative, interesting new UIs on top of the frameworks.
Activator should be part of the core OS - maybe not the ability to register any code to be an action, but at least allow application code to integrate with various system actions and gestures to provide a custom interaction layer. How great would it be if you could assign a long hold on the home button to Google search’s voice search URL to “replace” Siri? Or add a left-side off screen swipe that would launch an alternate app launcher? There are a ton of possibilities that could be implemented in a safe, sandboxed model with proper APIs.
Ultimately, I think this is just a long-winded way of saying that with a little innovation and creativity, Apple can open up a safe set of APIs that could rejuvenate iOS and make it compete squarely with Android.