The Truth Behind Apple banning Flash, MonoTouch on iPhone OS 4

1

Category : MonoTouch, iPhone

The real reason behind Apple’s changes to the  Developer Agreement is to keep the iPhone OS a unique, and exclusive platform.  Of course, that’s just my opinion.

There’s been much speculation about Apple’s intent with the new iPhone OS 4 Developer Agreement.  The popular opinion, and one which Apple is happy to publicly portray is that tools like MonoTouch, Flash, Unity, Torque (and there are others) somehow are responsible for creating slow, low quality apps with non-standard user interfaces that don’t take full advantage of the platform’s features.

Some Background Information
For a developer, the idea of code once and compile for multiple platforms has always been an elusive oasis in a desert of clumsy non-standard interfaces, and overly generic functionality.  It’s hard to get the best of both worlds, and often the best a developer can do is to build some common functionality with a cross platform language into a library that they can access code from with user interfaces for specific systems/devices, eliminating a good chunk of tedious work for much of the logic or ‘guts’ of their application.

Adobe’s Flash has been doing a pretty good job lately of trying to make this developer dream come true.  Adobe AIR accomplishes true cross-platform compilation pretty well and even has extensive integration with all the systems it is supported on.  They’re taking this one step further with Flash CS5 and apparently targeting several major mobile platforms, including the iPhone and Android, giving developers the ability to create their application once, and have it look, feel, and function the same across platforms.  I think it’s extremely important to mention here that Flash for the iPhone is not really Flash.  It’s simply a flash app that’s compiled to a native iPhone application.  So when people argue that flash is slow, and prone to crashing, that’s not a legitmate concern since it’s not really flash we’re talking about!

MonoTouch takes a different route by simply allowing code to be written in C# while targeting specific iPhone libraries.  MonoTouch gives developers access to all the same API’s that obj-c people have access to.  In fact, MonoTouch can even export an application to an XCode project.  In short, MonoTouch uses the XCode toolchain, does not try to reinvent user interfaces, and generally, produces very fast, standardized applications that too, compile into native iPhone applications bound to native iPhone API’s. 

So What’s the Big Deal?
In any case, there’s a good chance you’ve downloaded an application made with a tool like MonoTouch already.  Ever heard of Zombieville USA?  Well it was made with Unity, which borrows some of Mono’s functionality, the thing that powers MonoTouch.  My point is, apps made in these other languages are not necessarily any slower, or buggier than a good old objective-c app, and Apple could and should evaluate performance and bugginess of apps on an app by app basis, so arguing that these tools produce inferior applications is not a real excuse.

Think about this.  Why do people buy the iPhone?  It’s a nice piece of hardware, sure, but so is the Nexus One.  It’s got a nice operating system, but Android does some things better than it (eg: Notification organization).  People have an iPhone because of the Apps.  It’s Apple’s cash cow, and they need to hold onto it.  The only thing that truly sets them apart is the fact that there’s so many apps that don’t exist for Blackberry or Android, and that there’s so many apps that are better on the iPhone than their Blackberry and Android counterparts. 

Now imagine a bunch of flash developers start using Flash CS5 and all of the sudden they start making apps for the iPhone and Android at the same time, and that their apps look, feel, and function exactly the same on both platforms.  Now, do you still really want an iPhone?  Many people may still prefer the iPhone for various reasons (they are already comfortable with it, or Apple has already locked them into their ecosystem with iTunes, etc.), but many more people would feel free to move to another device.  This is not a new concept for Apple.  They’ve been making money by charging premium for their products based on the software and experience associated with their hardware.

The only thing I might give Apple some slack about is the possibility of Flash de-standardizing the user interface of the iPhone OS Platform.  It’s generally not a great thing to have every app with a unique interface and no consistency between them.  However, Apple could address this issue by rejecting apps on an app by app basis if they do not conform to user interface standards (similar to my previous sentiments).

What about MonoTouch?  The rest of the tools are just collateral damage.  Apple may not specifically care about killing them off, as MonoTouch for instance doesn’t threaten to make apps look and feel the same across all platforms, but for whatever reasons (perhaps legal), it’s easier to paint a broad stroke and wipe out everyone. 

Bottom Line
The key to Apple’s iPhone success is exclusivity, and it is in their shareholders’ best interests to maintain this success.  Keeping out apps that are identical across platforms means that Apple’s platform stays unique and keeps their users locked in.

Any negative press and lost app revenues from pulling apps that Apple incurs would ultimately be a minor setback compared to the gains from keeping the ball in their court in the long run.

I’m still optimistic about the situation and hope that Apple relents and allows the likes of MonoTouch to stick around.  There’s not really any certainty either way about the situation until Apple makes their stance more clear.

What do you think?

MonoTouch: Apns-Sharp Updated, and now Powering G-Push Mail!

12

Category : MonoTouch, iPhone

Some of you may not know that I am the author of a little free, open source library called Apns-Sharp (http://code.google.com/p/apns-sharp/)

Apns-Sharp is a .NET Library written in C# to help Developers create applications that interact with Apple’s Push Notification Service, Feedback Service, and iTunes Receipt Verification Service.

Apple Push Notification Services - Apns-Sharp for .NET / C# MonoTouch Developers!

Today is exciting… I’ve switched over my Production Push Notification Service that powers the app G-Push Mail to use the new version of Apns-Sharp!

First I apologize for the lack of updates to this project. It’s been too long! With that said, I’ve finally updated the project to 1.0.2.0 which includes a substantial set of changes to the Notifications library in particular.

Previously, I had taken the code I was using at the time in my application, forked it, and tweaked it into this library. I was too busy to actually switch my application (G-Push Mail) over to this library, and life went on. As I noticed bugs (some big ones!), I fixed them in my application, but those changes never made it to this project.

Well, I’ve finally got a chance to fix this library, and I’m announcing today that my production application: G-Push Mail is now running using the Apns-Sharp library! Basically, this means that the library will get more attention. Any time I notice a bug in my production app, or decide to enhance G-Push Mail’s apns capabilities, Apns-Sharp will benefit from the changes!

I do have to admit though, that the only part I’m using in projection right now is the Notifications. I don’t use In-App purchases in my app anymore, so I haven’t tested the AppStore part of the library very thoroughly. I do plan on using the Feedback library in the very near future!

Thanks to all those who have filed bugs, and continue to do so. I promise it won’t be months to fix any bugs that do pop up this time!

Last but not least, I need a shameless plug:  G-Push Mail iTunes Link

SEO Powered by Platinum SEO from Techblissonline