I am the engineer behind both Clear for iPhone and Clear+. Your statement could not be further from the truth - it has taken a lot of effort to make the iPad component.
I'll give you a taste of some of the work that needed doing (completely describing everything would take ages). Here's a few examples:
- With iOS7, we switched to using TextKit so that we can vary the text sizes (both internally and via Dynamic Text). This involved a significant refactoring as in the previous codebase, we had to hardcode offsets. Why was it all hardcoded? Anyone who's had to deal with the problem of editable inline text would know that there were no APIs to match the drawing of text and editing via UITextView (which was previously based on UIWebKit; while you could the drawing either via the convenience NSString methods or via CoreText; if you used CT, you'd end up with mismatched visuals when editing / displaying). Did you also notice that when completing items on iOS6, the strikethroughs extended beyond the text on items with more than 1 line? Not anymore, due to the new internals.
- The architecture on the iPad is completely different vs the iPhone - on the iPhone, you have a single "list view" (custom implementation to be able to provide all the advanced gestures). On the iPad, you now have two view controllers that need to stay in sync, animate in sync, etc. It also meant that I had to do significant refactoring to abstract away all the controller logic as it had to be embedded in different controller hierarchies - you really don't want to duplicate all that logic.
- List peeking on the iPad. This required adding support to both the list view and to the item views, again - something many people might not even use but it's extremely handy when you need it.
- Drag and drop on the iPad. iOS does not provide a standard API to drag between views, so I had to implement my own which is fully animated and interactive. Try to dragging tasks to lists on the iPad - the feedback is immediate and you will see the 3D animations when items drop. These are all little details but they take a lot of effort to get right.
- If you run the iPad app, you will see that it has a completely interactive tutorial. We spend significant amount of time on that, to make it feel super nice and provide the best way to acquaint users with the interface. Again, anyone who cares about details will tell you that the final 10% take a considerable amount of the total time.
- You're also not seeing a significant amount of research and testing. We had experimental interactions that never made it to production. We've made many prototypes throughout the life of the app, none of them publicly available. We learn a lot from these but that's all invisible to our users.
The above points just scratch the surface on the work that was needed to bring Clear to the iPad. I hope it illustrates the point that it's not a simple job of just recompiling.
The majority of those changes aren't visible to users. As a corporate developer, I can tell you that it's extremely hard to get funding to make even the most necessary technical changes to an existing piece of software. Normally, the best you can do is sneak it in with a big redesign that has features worth paying for.
The issue is that users have come to expect free updates for the life of the product. I've had five-star apps get 1 star reviews because 'it hadn't been updated in months' – in one case, with an app that already saw nearly three years of continually free updates that each brought a ton of (painstakingly) added technological complexity. Most of our users love the product. We've gotten an award, and have been featured by Apple.
Those 1 star reviews, as you know, are very detrimental. I've had one or two in the past because they _thought_ we were going to charge for an update that we announced.
Anyway, point being that while I feel your pain -- this stuff is never easy to build -- many users do not.
I'll give you a taste of some of the work that needed doing (completely describing everything would take ages). Here's a few examples:
- With iOS7, we switched to using TextKit so that we can vary the text sizes (both internally and via Dynamic Text). This involved a significant refactoring as in the previous codebase, we had to hardcode offsets. Why was it all hardcoded? Anyone who's had to deal with the problem of editable inline text would know that there were no APIs to match the drawing of text and editing via UITextView (which was previously based on UIWebKit; while you could the drawing either via the convenience NSString methods or via CoreText; if you used CT, you'd end up with mismatched visuals when editing / displaying). Did you also notice that when completing items on iOS6, the strikethroughs extended beyond the text on items with more than 1 line? Not anymore, due to the new internals.
- The architecture on the iPad is completely different vs the iPhone - on the iPhone, you have a single "list view" (custom implementation to be able to provide all the advanced gestures). On the iPad, you now have two view controllers that need to stay in sync, animate in sync, etc. It also meant that I had to do significant refactoring to abstract away all the controller logic as it had to be embedded in different controller hierarchies - you really don't want to duplicate all that logic.
- List peeking on the iPad. This required adding support to both the list view and to the item views, again - something many people might not even use but it's extremely handy when you need it.
- Drag and drop on the iPad. iOS does not provide a standard API to drag between views, so I had to implement my own which is fully animated and interactive. Try to dragging tasks to lists on the iPad - the feedback is immediate and you will see the 3D animations when items drop. These are all little details but they take a lot of effort to get right.
- If you run the iPad app, you will see that it has a completely interactive tutorial. We spend significant amount of time on that, to make it feel super nice and provide the best way to acquaint users with the interface. Again, anyone who cares about details will tell you that the final 10% take a considerable amount of the total time.
- You're also not seeing a significant amount of research and testing. We had experimental interactions that never made it to production. We've made many prototypes throughout the life of the app, none of them publicly available. We learn a lot from these but that's all invisible to our users.
The above points just scratch the surface on the work that was needed to bring Clear to the iPad. I hope it illustrates the point that it's not a simple job of just recompiling.