Updated: iPhone OS 4 SDK section 3.3.1 Changes

The brouhaha over the change in the iPhone Dev Program License Agreement should not come as a surprise to anyone. Yes, it proves Apple really wants to lock developers and users into their own extremely high-walled garden. But no, it will not kill any iPhone Cross Compiler platforms.

If you haven't heard about it yet, the iPhone OS 4 Dev kit became available this week. John Gruber found an interesting change in the Developer License Agreement. Essentially Apple is prohibiting the use of cross-compilers like Adobe's upcoming CS5 and Novell's MonoTouch that allow developers to create applications in other programming environments and still compile iPhone applications. Thus people who make a Flash game and then use CS5 to compile to iPhone or someone writing a mobile game in C# who uses MonoTouch to build an iPhone release will be violating the new License Agreement.

Many observers see this change as Apple's way of preventing CS5 from being a viable iPhone development platform (examples: 1; 2; 3) The question is why on earth would a company want to limit the avenues for development on their platform -- don't more developers mean more apps, mean more customers? Isn't this one of the reasons why Macs have such a small share of the PC market? One answer (that favoured by Apple fanboys -- see the Gruber links above) is that by forcing developers to build applications natively for iPhone (and iPad) with XCode and InterfaceBuilder, these application will take advantadge of the unique features that make the platforms compelling. This in turn will make for much better user experiences and thus Apple is just ensuring quality for the users. This is hogwash, Apple is a profit-oriented company that is deliberately trying to create as high-walled a garden as possible around the iPhone. By generating this lock-in they hope to lock-in all the profits for them. This is what the point of the company is: to make money for it's shareholders. If consumers don't like this behaviour they can buy other products. If you want to develop applications for a platform provider that treats developers well, then don't build for iPhone.

More importantly, I don't think this change will really stop cross-compiler platforms either. It will force some changes. As Gruber pointed out, tools like the Unity 3D package are likely unaffected by the new license since they generate an XCode project that the developer still has to compile into an application for the iPhone. While it is annoying to the developer, platforms like CS5 and MonoTouch can do the same -- re-engineer their products to generate a XCode projects and require that the developer compile the applications themselves. Apple might argue that this is prohibited as well but it will be much harder for them to discover the app is built this way. It will be interesting to see how Adobe and other cross-compiler developers respond.

Update:

As the tweets roll in it appears many commentators are interpreting the license language as impacting even tools that generate XCode projects (such as Unity 3D) -- including the reaction so far from Flash people. I'm not so sure it does. To go that far I think Apple would also be ruling out developers own configuration management tools or any third party tools that generate, package or build code. Even if this is true, how can they tell if the tools generate Objective C in an XCode project? Don't get me wrong: Apple deserves scorn from developers but their ambivalence verging on hostility towards developers is nothing new.

Another Update:

Apple Insider argues that the license change bans cross-compilers and is also reportingthat Flash Apps are disallowed because of multi-tasking and that this extends to all other cross-compilers: "It can't do this if apps are running within a runtime or are cross compiled with a foreign structure that doesn't behave identically to a native C/C++/Obj-C app."

Now this is a crock. I don't know about CS5 but tools like MonoTouch and other cross-compilers do not rely on a foreign structure -- the only way to get apps built with them on the iPhone currently is to bloody well compile them with Apple's SDK. It's just that some cross-compilers may automatically invoke said compilation so that the developer does not have to manually do it. Adding the language about requiring original code in Apple's languages and interpreting that as banning porting has nothing to do with multi-tasking. Apple is simply screwing over developers because they think they can.

Read more »

Blogging is hard!

Two months and only two posts. I'm not sure what I was thinking when I started this blog but I was certainly hoping to be more prolific than this. In retrospect I'm not sure why I had this expectation: I never finished my dissertation in grad school and I never published any of my research papers. The problem is that once you've done the research, had the idea or experience that is the germ of an essay, it's over and done with. Why revisit it to try and tease out clearly communicable thoughts to communicate to others, time to move on to something else new and shiny.

This is the great allure of programming to me -- you can have an idea, code it, debug it and ship it without having to explain it. Explaining something takes far too long and even then it's unlikely that your audience has understood your message. Writing is hard, very hard. These missives are meant to be short and to the point (unless you are Steve Yegge.. but his blogs ARE short and to the point, it's just that the point is really a very thick novel.)

Speaking of the point, I did have one... let's see, ah yes... Blogging is hard, very hard. It's hard because it's easier to go design a new feature and code it or to verbally market that same feature in a product meeting than it is to clearly explain that feature and document it in written human language. Coding allows you to be precise; even if you are a newbie or don't know what you are doing and are not keeping it simple and don't have clear requirements you can create a mangled method of some kind that works -- it will compile and run (and if you actually are smart enough to use TDD, it will pass your tests.) You get some sort of external validation and thus gratification on your creativity immediately. The same holds true for verbal explication; you can expound ad naseum and even if you've lost focus and shifted gears several times, if you speak with animation, conviction and passion you will be believed and will either sell your idea or at least what your audience PERCEIVES as your idea.

Unfortunately writing, especially the combination of succinct reportage and witty column that typifies the best blogging, is much more challenging. Not only do you have to force yourself to hit the keyboard and actually delve into your thoughts, but then you have to attempt to make it interesting and esthetically pleasing. The hell with that -- I'm going to go code, the compiler while it is judgemental is easily pacified... an external audience that cannot be browbeat or seen is much more frightening. But I want to get better at writing and I want to engage a wider audience so I can become a better professional and perhaps a better person. So instead of having an idea and then abandoning it either before starting to write a blog or giving up after jotting down hundreds of ill-fitting and awkward words that cry out for editing, I'm going to try to just post something -- at least once a week, if not more frequently. So when I have a rant about something I encounter, like my post about API docs yesterday, I'm just going to put it out here. Hopefully I'll get better over time, but instead of puttering away on half-finished, never-ending posts I am moving the suffering out to whoever reads this and resolving to just post. Enjoy.

Read more »

Generating API Docs and the Relative Decline of MS developer tools

Three years ago, when I left the Microsoft/.NET development world for the wilds of J2EE/JEE and the confusing alphabet soup of standards, JSRs, JEE server implementations, etc.  I was expecting poorer quality development tools, much harder to configure servers, and a nightmare of database adminsitration and sub-standard drivers.   A couple months ago I returned to the MS world.  I thought it was just me having a hard time re-adjusting -- .NET 2.0 (and now 3.5) and C# 2.0 and 3.0 are more nuanced and complex than .NET 1.1 and C# used to be.   But I've had my off-on-the-road to Damascus (yes, I'm mixing references badly) moment. Microsoft is increasingly going to lose developers to Java and Ruby and other platforms and toolsets that are easier to use, cheaper (free as in beer) and far less proprietary in scope.

The catalyst for my epiphany was trying to generate some simple html API docs for a couple of our larger assemblies at work.  In Ruby or Java or Perl this is pretty simply done -- point a configuration task (i.e. in ant or maven or in code) at the project/module/package and very quickly voila, a set of JavaDoc based html documentation based on the structure of the code and the annotation comments on methods and classes.  In the last few versions of Eclipse you just select Project | Generate JavaDocs  and select a location and in a few SECONDS you get simple API docs in HTML that are easily added to source control, can be diffed, put on just about any sort of wiki or website, etc.

So how does Microsoft with their expensive Visual Studio and their proprietary advantage generate .NetDocs?  They don't.  To be fair there is the built in ability for compilation to generate XML documentation based on the /// comments in the code.  But there is NO built in mechanism to generate API docs.  With Visual Studio 2002 and 2003 there was an open source project called NDoc which generated html API from these comments and integretated into Visual Studio and ran fairly slowly.  But it is no longer maintained.  For .NET 2.0 and newer (3.0 and 3.5 and soon 4.0) there is an open source project from Microsoft called SandCastle.  It generates really good looking .chm (compiled HTML help) documentation but does NOT integrate at all with Visual Studio.  I couldn't get it working until an answer on StackOverflow.com pointed to a blog posting that ran me through it.  Even though it does generate HTML, it is really aimed at creating .chm files which are binary.  You have to run a separate tool outside of the IDE to create this documentation and it takes forever (this is because it has to actually connect to MSDN to get some .NET dependency documenation because the .NET core libraries are not open). So something that works quickly and is much easier to set up and use with a FREE IDE and is cross-platform is much harder to setup, doesn't work as usefully and is not integrated well with the EXPENSIVE proprietary tools from Microsoft.  

Yes API Docs are not very important in terms of overall development tools and functionality.  But this pattern is repeated throughout the Microsoft toolset (with the possible exception of SQL server -- the 2008 version of the Management Studio is incredible!) To get better (read useable) refactoring and getter/setter generation for Visual Studio (so you don't have to type lots of boiler plate code) developers in the know buy ReSharper.  Nothing wrong with that, it's a great tool BUT it galls me to buy an IDE then buy add-ins for it when you get the same functionality for free with Eclipse (and NetBeans and so on).  When MS developers realize that developers on other platforms have as good or better tools and they don't have to pay for them, no wonder they be less enthusiastic about MS.

I could keep ranting about the alphabet soup of extensions and versions and platforms from Microsoft but I won't.  MS has historically made the best tools for both rapid development and for robust Windows development, tools that were the envy of developers on other OS and platforms.  That's not true anymore and I think MS will pay the price in terms of lost developers.

Read more »

Welcome

So a decade late I'm finally creating a pseudo (or is that sudo?) professional blog. I'm going to use this space to post rants, discussions, investigations or whatever in the hope of working on my writing and perhaps actually communicating something vaguely interesting to people who can't sleep and are addicted to the internet. The primary focus of this blog is the business and craft of software.  But I can't promise that I'll keep the political and the personal out of it. I hope somebody gets some enjoyment out of this

Read more »