Text

Extending the Lockscreen with LockPages

With the re-release of Forecast, I introduced a new package called LockPages to support adding additional pages to the lockscreen. LockPages is designed to be extended by other tweaks to add pages to the lockscreen in a compatible way. So how does it work. First, you need to implement a protocol in your tweak:

@protocol LPPage <NSObject>

// Return the view that should be shown on the page
-(UIView*) view;

// The priority of the page.  Pages will be ordered in descending priority order.
-(NSInteger) priority;

@optional
// Called as the page is being scrolled into view.
-(void) pageWillPresent;
// Called after the scrolling stops on the view.
-(void) pageDidPresent;
// Called as the page scrolling begins from this view.
// This is only called if the scrolling had stopped on this page.
-(void) pageWillDismiss;
// Called as the page scrolls out of view.
-(void) pageDidDismiss;

// Allows the page to override the idle dim time interval.
-(CGFloat) idleTimerInterval;

// Show the time in the status bar on this page.  Default is true;
-(BOOL) isTimeEnabled;

@end

The critical parts are returning the view to render and setting a priority. Pages are rendered in descending priority order. The optional methods allow you to react to page changes and to control dim time while your page is showing.

Once the page is implemented, you register the page while initializing your tweak using a single method:

[[LPPageController sharedInstance] addPage:page];

Only call addPage: once, though. If the page view is hidden or the -(UIView*) view method returns nil, the page will not be shown on the lockscreen.

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

Text

Jailbreak Drama

The recent release of evasi0n7 was a surprise to all of us. I had no idea that the team was this close to a jailbreak for the public - and I’m obviously not alone. But all the drama surrounding this jailbreak release is truly perplexing. Did they release early because they wanted to be the first ones out? Did they release because of some mysterious lucrative contact with a Chinese company?

Regardless of the reason, the release was obviously rushed and we might never know the true reason it was released prematurely. I will say that if it was financially driven, so be it. Anyone that has worked for a profitable company knows what it means to need to be “first to market’ and that pushing mostly-baked code based on an arbitrary, contract-driven date is common - far too common.

The developers behind evad3rs deserve compensation for the work they do - it’s difficult, time consuming work that millions of people use and never pay for. What I’m not sure about is how they went about getting paid. The Chinese company that they partnered with is obviously very sketchy. The evad3rs claim that they didn’t know about the piracy and that Taig was contractually obligated to remove piracy. I don’t know if that’s true - I don’t work with the evad3rs or have any more information than everyone else has. If they knew about the piracy, shame on them. If not, shame on Taig. Regardless, the evad3rs’ decision to include Taig’s app for financial compensation is not wrong - it’s how business works.

Now onto piracy…

Piracy is piracy. The people that steal apps are going to steal them no matter how hard you make it. If the evad3rs hadn’t included the Taig app or the Taig app had removed all pirated apps in it’s store, users that want to steal the hard work of developers would just add the well-known piracy sources to Cydia directly. Piracy in the jailbreak world is not new - it’s been there as long as I’ve been in it, and over 90% of the users of my apps never paid for them - that was all before Taig.

What’s more concerning about the Taig thing is it somewhat legitimizes piracy (even if the evad3rs don’t directly support it) because it supports the widely (and incorrectly) perceived link between jailbreaking and piracy. I can’t tell you how many times I’ve had to explain the difference to someone I tell about my apps. I don’t work with or know a single person that has stolen a single app after jailbreaking - but those people do exist.

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).

Text

Charging for Change

I don’t like it when developers charge for product updates. I feel that it’s unfairly punishing consumers for decisions the developer has made. If a developer has chosen a sales model based on an up front software purchase, they should expect that their revenue stream from each consumer ends at the point of sale. It’s not the consumer’s fault - it’s the developer’s.

Developer’s might argue that they need to absorb the costs to maintain and develop updates for their apps when the platform they develop for changes (i.e. updates for iOS7). But this rationale is flawed. Any vibrant and high quality platform (iOS included) is built around backward compatibility. All iOS6-developed apps will work fine on iOS7. Will they look great - maybe not. Will they take advantage of all the great new things iOS7 offers - no. Is that the consumer’s fault - no. If the developer doesn’t want to update, they don’t have to - and if consumers complain and choose the competitor’s product, that’s free market economics for you.

If the developer depends on continued revenue, there are several options:

  1. Use in-app purchases to offer add-ons or additional features that don’t come with the base app - but don’t convert previously free features to paid features to monetize.
  2. Use a subscription model - if the user goes into the product expecting a $5 per year payment, that’s fine - it’s a decision the consumer made.
  3. Come up with new ideas - one-trick ponies will always run out of revenue streams. If you want to grow, grow your portfolio.

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

Text

LockInfo 7

Even though iOS7 hasn’t been released and there are only passing rumors of a possible jailbreak for the new OS, I get a consistent flow of questions about the future of LockInfo. This short blog is intended to be as transparent as possible and give you all the information I know at this point.

I do intend to develop a new version of LockInfo for iOS7. It will be another complete rewrite though since there have been significant changes to the way notifications work and how they are presented in the new OS.

The version would be LockInfo 7. LockInfo 5 was the fifth version and supported iOS5 and iOS6. But many people were confused by this. Since the new one would only support iOS7, it will be LockInfo 7.

The update will be free. Just as with all other LockInfo updates, I will be providing the update for all current licensees for free.

I have no idea how long it will take to get the update done. I don’t have a jailbreak, I don’t know when the jailbreak will be available, I haven’t even looked through dumped headers to see what has changed. Even if the jailbreak comes out on the first day iOS7 is available, it will take a while to understand the changes and rewrite the code to work on the new OS.

I am also very busy with things outside of the jailbreak world. The jailbreak community has changed a lot of the last couple years and so have I. I have other focuses that reduce the time that I have available to work on tweaks. I will make every effort to be quick, but things happen.

And of course, I do reserve the right to change my mind. I want to make a new LockInfo, and I plan to try. But if life gets in the way, I can’t control that. I will continue to support the current version of LockInfo, but any future releases are dependent on time, resources and complexity.

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.

Text

I Hear You…

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.

Text

LockInfo 5 Plans

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.

Text

Android for an iOS Developer - Day 1

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.

Text

An Open-er iOS

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.

Text

Car Infotainment Systems - the next smartphone

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.

Text

A Problem With Covers

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).