Ramblings of an iPhone developer

This is not goodbye, but simply "see you later". If time frees up and the inspiration hits me, I'll come back to iOS. Thank you all for your support over the last 6+ years.

If you purchased LockInfo after July 1, 2014, you will not need to pay the upgrade fee.

Please recognize that I need support from testers to help out. I obviously do my best to not introduce crashes and of course my tweaks are not crashing on my device, but crashes happen and conflicts happen. Without the logs, I'm lost.

Make sure your project links to the dylib linked here and depends on com.dba-tech.lockpages.

The long and short of it is, the evad3rs made a mistake. If it was an honest mistake, give them a break - they are only human and everyone is entitled to make mistakes. If they intentionally included a piracy app for financial gain, they are just as bad as the people that steal the apps. But in either case, their actions should not derail the jailbreaking community - there are millions of honest people that like to jailbreak to make their phones do things that Apple doesn't want them to do (Apple: just open up iOS, please...). I plan to continue to develop for jailbroken phones (though it's going to take a while to catch up this time).

In short, don't punish your consumers for decisions you make. It's a great way to piss off your consumers.

Please refrain from asking about ideas, screenshots, mockups or betas. I don't have any (except for a few ideas) so there is nothing to share right now.

Firstly, thanks to those of you who have taken the time to explore LockInfo 5 and helped other people out with questions and concerns. It's always nice to have people "in the trenches" helping out while my inbox is getting filled with emails. To those of you that have voiced concerns about the direction LockInfo 5 has gone, it's worth reading my blog http://blog.dba-technologies.com/pos...kinfo-rebooted to understand the design thoughts I had when approaching this project. The decisions were not made haphazardly. My rationale for the rewrite, for those of you who are not technical, is that the original LockInfo code base, the one that powered LockInfo 4, is three years old and is based heavily on code that existed back in iOS3. It didn't leverage new frameworks like Theos or new iOS frameworks. It didn't integrate will with the notification system and resulted in a lot of inconsistency with the state of the system. The iOS ecosystem is very different now and the maintenance costs of LockInfo had reached the point that a rewrite was necessary. And when it came time to rewrite, I also looked to simplify the overly complex settings that LockInfo 4 and earlier came with. I do want to have satisfied users. I do want to continue to iterate on LockInfo 5 to provide a tool that everyone will enjoy using. That will not be LockInfo 4 on iOS6 - that's just not going to happen. But it will be a new LockInfo that supports some of the features of LockInfo 4, but many that LockInfo never had. It will support a standard plugin architecture that will allow it to use any NC widget. If there are usability issues that you feel need to be addressed, email me. I may not be able to reply immediately (I'm focused right now on license issues and critical bugs) and you may not see those features immediately in the product, but I do want to continue to improve LockInfo. Email me at support (at) dba-technologies (dot) com. All I ask is for the conversation to be constructive.

Now that the iOS6 jailbreak is imminent, you might be wondering about plans for LockInfo. LockInfo 5 has been in alpha testing for quite a while but little work has been done on it recently due to the lack of a real iOS6 jailbreak on the horizon. Now, work is continuing aggressively to get it ready for a real release. New features are showing up and bugs are getting fixed left and right. Based on the recent DMCA exception changes, I don't know yet what I will be doing with iPad support. If it's illegal to jailbreak an iPad, it's going to be difficult to develop the tweak really. But I plan to follow the jailbreak team's lead on this and see what happens at release time. iPad support is mostly there, except for some odd unique issues that I need to work out. I hope to have a beta release of LockInfo 5 in the next week and a final release shortly after.

So I'm trying a little experiment... it's called Android. I've been bored with iOS on my phone for a while, especially without a jailbreak in order to make it work the way I want. So I started toying with the idea of trying something else. Windows Phone is cool, but the app market is so thin right now, it's just doesn't work. BB10... well... So that left Android. But if I was going to do it, I wanted to make sure I could use the latest and greatest... so I picked up a used Galaxy Nexus from an awesome follower in Twitter. Day 1 ------- Today is my first day on Android. The Galaxy Nexus is a decent device... no iPhone 5 though. The build quality is decent, the internal speaker **sucks**. The notification LED is nice. The screen gathers oil like the Gulf of Mexico. But for a trial device, it's a great place to start. The device was already rooted and ready for JB 4.2.1. I immediately installed the AOKP ROM and the Gapps. So far, so good. I've been fooling with different launchers and tweaks and I do admit that the customizability of the OS is nice - but in many ways it's confusing as hell - and very inconsistent. Once I get things in order and get used to it, I think it will be a nice place to be. I'm a bit frustrated that my corporate Exchange profile doesn't allow me to use lockscreen widgets on JB 4.2 - or at least I haven't figured out how to yet. I'm sure there are ways to do it on a rooted device - considering I could do things like wipe out the entire profile on iOS once it's jailbroken with no issue at all. We'll see. So it's just the first day - too early to have a real opinion. I'm determined to give it a few weeks. I don't think this is me leaving iOS - I still love my iPad mini. But I needed something different in my pocket.

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: 1. 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). 2. Jailbreaking requires a lot of work from a lot of smart people to find vulnerabilities so it's an inherently unstable and unpredictable process. 3. Utilizing code swizzling and substrate code injection results in frequent code conflicts - tweaks constantly collide and result in crashes and unintended side effects. 4. Since most tweaks need access to undocumented APIs, it's often difficult to find the right APIs to accomplish a task. 5. 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"? Lockscreen == 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. Gesture/Activation == 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.

Prior to the introduction of the iPhone, mobile phones were a buy and forget commodity - you bought a phone and the features and capabilities that came with it were all you got. No updates, no enhancements, no nothing. Not even fixes (ok, maybe some critical ones). But the iPhone changed that. Now, you buy an iPhone as an investment for a couple of years and get multiple updates throughout it's life to add features and fix issues. I know several people that are still happily using their 4 year old iPhone 3GS on the latest OS with no issues. All modern mobile OSes follow this model with varying success (some low end Android phones never see updates, but that's generally an exception). For years, the complexity and capabilities of car infotainment systems have grown. Navigation systems, voice control, media players with hard drives, google earth integration with navigation, personal hotspots, streaming internet radio, etc. I would argue that most of this explosive growth in features for car systems is the direct result of the evolution of mobile computing - people have mobile computers that can do all of this stuff, why can't their cars? But here's where the similarities end. Whereas the upgrade cycles of mobile phones are pretty consistent and have become the norm, car infotainment systems **rarely** ever see updates. You spend $40,000+ on a premium car and you will likely never see any new features or capabilities added to it... ever. And that car you will keep for years. In my opinion, the correlation between the current state of car systems and feature phone OSes of the past (circa 2000) points to a ripe market for a revolution. The car manufacturers - companies not known for software technology innovation - are developing these systems with horrible user experiences, slow designs and missing features. Why not standardize the system hardware and allow companies that know how to build great mobile software (Apple, Google and Microsoft) build the OS? Let's hope this happens in the next few years... I want to jailbreak my car.

I love my iPad mini - it's with me everywhere. I read on it, watch TV on it, tweet on it, mail on it and Letterpress on it. I actually use it more than my phone now. I also love the Apple SmartCovers. They are elegant, durable and fit so well. But with the mini, Apple introduced an adapted cover for the form factor. Instead of four separate elements that fold over to create the typing stand, it only has three. At first, I wondered how that was possible. The full iPad one needs all four elements to create the stable stand. But Apple is creative - they placed the magnets on the very tip of the cover so they catch when you fold it over. But that design even has it's own issues... There are two methods for folding it: full "inside-out" fold so the soft suede interior is showing (ala full iPad) or "outside-out" with the smooth exterior remaining on the outside - because of the magnet placement, both are possible. **Inside-out** The traditional inside-out fold is just not as stable on this cover. For one, without the plastic hinge from the full iPad, the mini is rather wobbly when you try to type. Additionally, the size of the elements are such that the center of balance for the stand is too far back - I've had the whole thing collapse under me while typing.  **Outside-out** The opposite, outside-out folding offers a much more stable base, but because the magnet catch is so small and the cover hinge doesn't rest over the magnets, it's far too easy to push too hard at the top of the mini and collapse the stand.  Some people might think I'm being overly picky, but I use this thing for everything I do - not having a stable stand to type on is a bit of a pain. Hopefully there will be third-party alternatives or an iteration of the cover to improve this (doubtful).

When the iPhone 5 was released, Apple stated that they would not be releasing a dock to accompany the new device. This was a disappointment to me. I use my phone as an alarm clock too and like the ability to see the screen when my alarm goes off. It's a minor annoyance, but I'd still like the option to put my phone in a dock at night. Enter kickstarter... I feel like there is a new EvolutionLabs-wanna-be kickstarter project every week claiming to have the next novel idea in producing a simple dock for the iPhone 5. But at $70+, that's just too rich for my blood - especially for a dock that's just going to sit on my bedside table. Then I found the Belkin Charge + Sync Dock (http://www.belkin.com/us/F8J057-Belkin/p/P-F8J057). It's cheap and available now. So I ordered one. I got excited cause it looked like a good dock. Well, at first I was a little disappointed. See, since Apple introduced the lightning cable with a security chip, third-party accessories like a dock require the standard cable be hacked into the dock to provide the power/syncing and the dock is simply a housing for it. In the case of the Belkin cradle, that housing isn't nearly as tight as it should be. Out of the box, when you pull your phone out of the dock, the cable is pulled out with it. Annoying. In the end, there is a very simple solution. I was always taught that if duct tape (or electrical tape in this case) can't fix a problem, it's unfixable. Wrapping the iPhone lightning cable with a few turns of electrical tape around the part that sits in the channel under the dock provides just the right amount of tension and friction to keep the cable from sliding while still allowing you to remove the cable if you wish. In the end, it's a good dock. It serves it's purpose, even if it's not as pretty as Apple's old docks.

Every once in a while, you need to reboot. Software, like anything that can atrophy, can reach a point where is just better to start clean, both with new code and new ideas. LockInfo, after a three year run has reached this point. LockInfo is getting a reboot. ****What I've Learned**** A lot has happened in the last three years that have influenced where I'm taking LockInfo. First and foremost, with the introduction of Notification Center, I made the decision to keep LockInfo mostly unchanged. Some people liked this, many people thought LockInfo felt disjointed with iOS. When I originally developed LockInfo, I was introducing new features into iOS 3.x - now with Notification Center and iOS5, those design decisions didn't feel as natural. Rather that fight the design of Notification Center, I've decided to embrace it. LockInfo already had a "custom" Notification Center option. This feature has now become the ****standard**** way LockInfo integrates with Notification Center. InfoShade is dead - LockInfo's shade is now a ****very**** enhanced Notification Center. On the lockscreen, I felt that simply showing Notification Center just didn't feel right. Apple's approach actually makes much more sense. On the lockscreen, you are looking to see a stream of things that have happened since you were locked. This is why iOS5 used a different model of non-categorized notifications. Still, there were some things missing. First, sorting through a lot of notifications is a pain. In LockInfo, I'm adding a "filter" bar to the top that allows you to filter down the notifications to just the types you want to see. Additionally, the filter bar allows you to clear all of the notifications in a filtered set or all of the notifications at once. The lockscreen was also missing widgets. It just didn't make sense to me to try to shove widgets in with the notifications. First, there's not as much space. With the lock bar and the clock, screen real estate is premium on the lockscreen. Also, since the notifications are not categorized (remember, they represent a stream of missed events on the lockscreen), there's no natural place to mix them in. Instead, the filter bar acts as a separator between notifications and widgets. To see your widgets, you grab and pull the filter bar down. There are your widgets. ****Insanely Simple**** LockInfo, in it's current state, is complex. While I developed it, I didn't think very holistically about how a user interacts with the tweak. The number one complaint I've heard (directly and indirectly) is how complex it is to set up. The complexity afforded a lot of customizability, but it also made the tweak difficult to manage and configure. The new LockInfo is dead simple. The tweak settings are tiny. There are a handful of simple settings embedded directly in the settings for different notifications, but that's it. It just works. ****LIV (LockInfo 5)**** My number one focus in rewriting LockInfo is to make it much lighter, simpler and more integrated. I want LockInfo to feel like what iOS5+ should have felt like in the first place. Thanks to some modern frameworks and tools (thanks dhowett for the supremely incredible theos/logos system) and a vastly improved understanding of iOS SDK and core frameworks, LockInfo is becoming alive again. With a change this significant, of course, comes some compromises. First, I am not planning to support custom plugins anymore. Though I liked the idea, in theory, in practice it was more complicated that it was worth. People wanted to install a package and be done. LIV will support any WeeApp (NC widget) that is installed on the device so you can still get custom data on your screen that way. Second, themes are gone. I know people like to customize the look of there systems. Since my goal is to make LockInfo feel like iOS, I'm not using ****any**** custom images which allows themers to use Winterboard to replace any of the system images to make LockInfo look just like the rest of the system. It just feels more natural that way. The homescreen option is gone. Based on my research, it was a rarely used feature, and when it was, it was just to support the widgets on SpringBoard. Tweaks like DashboardX do a ****much**** better job of this and make a homescreen option for LockInfo basically useless. In the end, I am ****extremely pleased**** with where LockInfo is heading in this release. It's lighter, faster, easier, cleaner, more natural and more integrated than any version of LockInfo has ever been. I can't wait for everyone to see where LockInfo is going. Enjoy a little clip of what the next LockInfo, LIV, will look like: http://www.youtube.com/watch?v=r-PaEBN9108

Sad.

And don't get me started on in-car infotainment systems. What a gold mine for true iPhone/iPad integration.