Thursday, March 27, 2008

On Managing iPhone & Mac Developers in the Enterprise

Apple seems to be positioning the iPhone as a competitor to the Blackberry, Treo, and other so-called smartphones commonly found in the Enterprise, and this fact has stirred up a lot of interest in the iPhone and the iPhone SDK. As a result, people with a lot of Cocoa programming experience suddenly find themselves marketable beyond the realm of the Mac. 

For companies who want to get something solid up and running on the iPhone quickly, there's really no better choice than to hire a couple of people with solid Cocoa development experience. They will hit the ground running, whereas other developers with no exposure to Xcode or Cocoa are going to have a solid learning curve facing them. People will tell you that Cocoa is easy to learn - and it is - but, like anything, it takes people a while to really wrap their heads around it fully. 

But here's the rub: Mac developers, by and large, are a different breed than the developers you're probably used to working with in your large corporate environment. The majority of them are self-employed, part-owners of a small software company, or work in small, fairly autonomous groups within a larger organization. They are used to working in an environment that is the polar opposite of what most corporations and other large organizations foster. They are not accustomed to (and many actively avoid) bureaucracy and committee-based decision making, and they are accustomed to a lot of freedom in choosing how and when they work as long as they meet deadlines and deliver a quality product.

One of the first things you need to understand about Cocoa development (and it seems almost certain that this will apply to Cocoa Touch just as much), is that the entire language and the development tools are setup to afford maximum productivity to individuals or small groups, not to facilitate large groups of developers, analysts, architects, and other pseudo-developers.  Cocoa groks the ideas found in The Mythical Man Month and rarely do you find Cocoa projects using more than a handful of developers. Do you know how many developers wrote iMovie '08? One… and he wrote it while on vacation.  There are, in fact, many examples of great software on the Mac developed in Cocoa by just one developer, and a great many more that were developed by small teams. 

So, the first rule for your iPhone team: less is more. You'll do much better getting a couple of really good, experienced Cocoa developers than a dozen coders of mixed experience levels and background. If you can't find any, invest in a good people and send them to the Big Nerd Ranch to get trained up, put them in front of a nice powerful Mac, and let them at it.

Second rule: don't ride herd on them. Get people in whom you have a high level of confidence, and then let them do their job. This is probably good advice for all employees and all development teams, but I've worked inside large organizations enough to know it's not standard practice. Resist your impulse to micromanage. It's a bad idea in general, but it could be devastating to your iPhone development team, especially if you followed the advice of my first rule and hired good, experienced Cocoa developers.

Third rule: insulate your team from corporate silliness to the fullest extent of your power. Nothing will make these people leave your employ faster than making them sit in unproductive, boring meetings that don't directly further the project. The kind of person you want, wants to be sitting in front of a Mac furiously coding away. Anything you make them do that's not that, is counterproductive and damaging to your project.

Fourth rule: forget your existing processes, project plans, and other schemes for world domination. They don't work to begin with, but they are blatantly fatal to this kind of software development. Too much process with kill your iPhone development projects faster than anything; every existing packaged process scheme is a case of the cure being worse than the disease.  The iPhone tools and design patterns are not built to accommodate the kind of oppressive over-processing mechanisms that are all the vogue in enterprise software development these days. You'd probably get more done if you abandoned it for all your software development, but in this case, it's mandatory. If you use these tools, you will fail. If your corporate policies say you have to use them, get an exception, or else outsource your development to someone who's not fettered by silly corporate rules. If you try to force CMM, RUP, SCRUM, Six Sigma or any other form of expensive snake oil that your management thinks is the silver bullet onto your iPhone development team, you will smother it until it dies a painful death.

That's about it. I'm not a management expert, but I know Mac developers, and I know enterprise IT, and I foresee trouble brewing if those in the latter insist on trying to force those in the former into a mold they are not intended for.




Beta 2 is out!

If you're a registered iPhone developer, go get it!



Monday, March 24, 2008

Getting Started on the iPhone: A Primer for Non-Mac Development Shops

What do you do if you're an existing software provider and you want to get into doing iPhone Development? Well, if you're already a Mac developer using Cocoa, you're probably already elbow-deep in the SDK and having a blast. But if you're a mobile developer who has worked with other platforms, or if you are primarily a Windows or Java shop,  the prospect of getting into the iPhone is probably daunting. You've likely had some of your developers sign up for the SDK and start reading up, and chances are they're having a a lot of big WTF moments.

So, let's take it step-by-step. How do you get up to speed quickly if you're completely new to objective-C, Cocoa? Here's a high level plan for you.
  1. Join the Apple Developer Connection or ADC. This is Apple's developer support organization, similar to MSDN. There is a free membership available, but splurge for at least the Select membership, which entitles you to a hardware discount, some one-on-one support with Apple engineers, and access to Apple's compatibility labs. You'll also become seeded, which means you'll get early access to software, including versions of the iPhone OS. If you're serious about bringing existing applications to the iPhone as quickly as possible, consider splurging for the Premier membership. Make sure anybody on your team who's going to be looking at the SDK signs up with at least a free membership so that they are covered by the iPhone SDK.
  2. Have your developers learn Objective-C. At first, don't worry about Cocoa (the application building framework), just have them learn the syntax and nuances of the language it's based on. Your more advanced developers can probably get by with just reading Apple's language reference, as it's a relatively simple superset of the C language.  There are other books that will take you a little more by the hand through the language for people who need it. Unless your folks have worked with something like SmallTalk before, some of Objective-C's syntax is going to feel alien at first, but it's really an elegant and rather fun language to work with once you get over the initial hump. 
  3. Buy some Macs. If you've downloaded the SDK, you've probably already figured out that you need a Mac to code for the iPhone. And you need an Intel Mac, and it has to be running Leopard (the latest version of Mac OS X - it's version 10.5). If you joined ADC as I recommended above, you can get a substantial discount on buying your hardware, which is why I had you do that before buying any hardware.
  4. Learn Cocoa. Cocoa Touch is a bit different from Cocoa, but a lot of the design patterns, and all of what Apple calls "Core Foundation" is common between the two, so it's a good idea to learn it, even though a lot of the stuff won't be directly relevant to coding for the iPhone. The Big Nerd Ranch offers training classes in Cocoa that are supposed to be excellent. There are also several books out there on programming Cocoa, unfortunately, as of this writing, none of them have been updated to use Objective-C 2.0, the version of the language used to develop for the iPhone.
  5. Start dissecting the sample code. Play around with the iPhone templates in Xcode, and browse the API documentation. Experiment. Play. Do a bunch of stuff wrong before starting on porting or re-writing any of your applications.
Okay, I know you were expecting something better than step 5. Unfortunately, because the iPhone SDK is under NDA, and will be until June, nobody can publish books or articles on how to code in Cocoa Touch until that time without violating their NDA. Places like the Big Nerd Ranch can't offer classes prior to June (although I notice they're thinking ahead and have an iPhone class scheduled for September - sign up now if you're interested, their classes often sell out).

If you want to be one of the first ones out of the gate, and you aren't a big enough company to warrant special attention from Apple and don't have deep enough pockets to lure away their existing iPhone developers, you're basically stuck with this approach for now. You need to let your developers experiment in lieu of formal training, or else you need to resign yourselves to waiting and losing the competitive advantage of being an early entrant into an emerging market.




Thursday, March 20, 2008

Network Communications with NSFileHandle

Okay, well, because of the NDA, I can't post code samples about how to do things using the iPhone SDK yet, but I can post regular old Cocoa code without worrying about the Apple lawyers. If that code just happens to be usable on the iPhone also... oh, well.

With the fact that so many people have downloaded the SDK, I have to think at least seven or eight of those people do not have any prior experience using Objective-C or Cocoa. Those people will have a bit of a grokkng curve. I say "grokking" instead of "learning" because the syntax of Objective-C is straightforward and relatively easy to learn. However, the approach it takes is decidedly different from the application frameworks used with Visual Basic, C#, and Java; it takes a little while to really understand the way it all fits together and start working with the frameworks rather than against it.

One of the things that I'm sure many aspiring iPhone developers will want to do in their applications is to communicate with remote servers. Now, any of the old school C programmers who want to do so will have access to BSD sockets and can do network programming just as they have always done. Because Objective-C and Cocoa build on top of C, you always have available to you everything you do when writing procedural C.

But, often, there's a better, or at least, an easier way to do things using existing Cocoa classes. Unfortunately, what that "better way" would be for this isn't quite so straightforward. One option is to use CFNetwork. CF stands for Core Foundation, and when you see something beginning with CF in the world of Apple software development, you are looking at lower level C functions that are used by the higher level libraries like Cocoa and Carbon. CFNetwork underlies many of the higher-level classes capable of communicating with remote servers. When you use NSURLConnection, or instantiate an NSString using stringWithContentsOfURL:encoding:error:, you are using classes that sit on top of CFNetwork.

And CFNetwork is great - it is robust and written to work with an existing run loop mechanism, meaning you don't have to detach threads to keep from blocking. Unfortunately, CFNetwork is conceptually hard and using it in Cocoa creates confusing, hard to maintain classes. Coercing C callbacks into an instance of a Cocoa class works, and it works well, but it just doesn't feel right in the context of Objective-C/Cocoa.

Unfortunately, there is no generic Cocoa class for accessing remote servers. There are lots of special-purpose methods and classes that sit on top of CFNetwork and let you seamlessly get information from over the network using URLs. But what can you do if you want to implement your own protocol, or access a different kind of server?

Well, there are several third party classes that you could use for this, including Dustin Voss' free AsyncSockets and the open source SmallSockets project. These are both good options if you want to use them.

Someone on the Cocoa-Dev mailing list recently pointed out that NSFileHandle is capable of handling socket communications, but you have to actually create the socket the old fashioned way and feed it to NSFileHandle using initWithFileDescriptor: to do so. Thanks to the beauty of Objective-C categories, however, you only have to do it once if you write the code generically and put it in a category.

So, thanks to the help from several people on the Cocoa-Dev list, I present a category on NSFileHandle that lets you get a conection to a remote server. You can download the category right here.

Using this category is very straight forward. You can create a new NSFileHandle that is connected to a remote server like this:
NSFileHandle *fh = [NSFileHandle fileHandleToRemoteHost:@"theremoteserver.com" onPort:80];
To send a command and get the response, you need to create a method (probably on your controller class) that will be called whenever data is available on the read stream. That method might look something like this:
-(void)process:(id)notification
{
NSFileHandle *fh = [notification object];
NSMutableData *data = [fh availableData];
NSString *dataString = [[NSString alloc]
initWithData:data
encoding:NSUTF8StringEncoding];
/* Process the data however you need to here */
[dataString release];
if (booleanVariableThatIndicatesIfWeExpectMoreData)
[fh readInBackgroundAndNotify];
}
Notice the last two lines. If we are expecting more data, we have to call readInBackgroundAndNotify again, or it won't continue to pull more data from the stream and we'll end up with only part of the server's response. If we don't expect more data, we don't have to call readInBackgroundAndNotify any more, and could also close the stream using the closeFile method of NSFileHandle. You could also leave the stream open and send more commands to it. 

If you call readInBackgroundAndNotify and there's nothing to read, your program won't be harmed, but your method won't get called again unless you send another message through to the server. So, if you have processing to do on the retrieved data once you get it all, you need to figure out in your code when you've received everything. Usually the protocol gives you a mechanism for doing that. NNTP, for example, sends a line with just a single period on it to tell you when it's done sending you data, but it leaves the connection open in case you want to send more commands through.

The nice thing here: no threads. Our application goes about its merry way, and calls us back when there's something for us to do. At this point, we've created the file handle, and we've created a method to process the responses from the server, so now we just need to send something to the remote server so that our process: method has something to wait for, which we do like this:
[fh writLine:@"HELO\r\n" withObserver:self andProcessWith:@selector(process:)];
That's all there is to it. 

As I said before, this is Cocoa code, not Cocoa Touch code, but since NSFileHandle is part of the Foundation framework and not the AppKit, it should (in theory) work unchanged in Cocoa Touch. I haven't yet tested it, but I'm going to, and as soon as the NDA lifts in June, I'll tell you if any changes are necessary to get it to work on the iPhone.




Tuesday, March 18, 2008

Problems Reading and Writing Files on the iPhone?

If you're having problems reading or writing data using the beta iPhone SDK, you should head over to the iPhone Dev Site at Apple, and download the SQLiteBooks sample code they just posted. There's a workaround in the App Delegate of that project for the problem. 

I can't give details because of the NDA, but if you're trying to do any file reads or writes, or to use SQLite, you should check out the new sample code to find out how to get those working.




Monday, March 17, 2008

Brain Surgery?

Craig Hockenberry has an interesting post on his blog today about the iPhone background processing issue. Craig speaks from personal experience on this matter and I'd classify his post as a must-read  for anyone who has an opinion on the background processing issue in the official iPhone SDK.

Unfortunately, his posting comes off as a bit smug and superior for my personal tastes. Though I have tremendous respect for Craig's ability, this posting comes across as a "shut up you naughty children, you're not as smart as me and Apple so you can't have an opinion on this". It is definitely true that he has first-hand experience that most of us don't, but since the decision he's justifying is one that prevents us from gaining the very experience he's claiming we need in order to have an informed opinion (without jailbreaking our phones, at least), I'm finding the argument a bit circular for my taste.

To work with Craig's own metaphor: Don't cut off our hands to keep us from shooting ourselves in the foot. Some of us idiot developers who are apparently not smart enough to have an opinion on this, might just surprise you by finding a way to work around the problems you encountered. Or, just maybe, our applications have different background processing needs than the one application you've tried this with. Since Apple has set themselves up as gatekeeper to the App Store, and since no self-respecting developer is going to ship a product without testing it extensively on a real iPhone first, I don't see the need for such drastic exclusions from the SDK itself. They could control this by subjecting apps that use background processing to greater scrutiny, or providing a sanctioned mechanism that can enforce limitations, not by making those parts of the iPhone completely verboten.




Sunday, March 16, 2008

The iPhone and the Enterprise

With Apple's simultaneous announcement of the iPhone SDK and the licensing of the protocol needed to work with Microsoft Exchange servers, it does seem like Apple is finally getting serious about pushing into the Enterprise. I've worked a lot in this realm, and have long felt that Apple's development tools - especially Cocoa — which started life as NextSTEP — was especially well suited to doing the type of custom development that I've seen such a desperate need for in the Enterprise. Though most people aren't aware of it, the tools underlying the iPhone SDK as well as those commonly used for doing software development for Mac OS X have long-since been proven in the Enterprise environment.

I've spent spent close to a decade working in Enterprise software, first as a developer at PeopleSoft, and afterwards as an implementation consultant. During most of this time, I have wished there was some way to convince all these big, predominately Windows-based shops that there was something better available. But "Apple" is a dirty word in most large corporate IT departments, and Apple has never really seemed interested in challenging that. Old ideas persist long after they are no longer supported by facts. The fact that OS X is a solid Posix-compliant Unix which runs Microsoft Office, supports Windows printing and file sharing, and has virtually no impact from viruses or malware doesn't seem to hold much sway even when it is known. It is sheep mentality at its worse, but there it is. 

Large corporations are not known for encouraging individuality, and no decision is ever made by a single person at most large companies. I think Heinlein's description of decision by committee is spot on: He described a committee as a beast with multiple heads and no brain. Any committee is less likely to reach the right conclusion than any individual member is. The whole is considerably less than the sum of its parts in this context.

Most of places I've done work for also balk at even hearing the term "custom software"; bizarrely enough, they are frequently willing to spend literally millions of their corporation's dollars to implement so called "Enterprise Software" - software to handle some set of tasks less efficiently than what they could have had by hiring a couple good Cocoa developers for a month. These projects often fail, and rarely do they come in on-time or under-budget, even when the schedule and budget are luxurious. Despite that, suggesting to a large American corporation that they develop in-house solutions in Cocoa would be openly laughed at. "It's not Windows" has been a sufficient argument against that idea for well over a decade now.

In the short term, I do not see the situation changing, but if the iPhone sees any serious penetration into the Enterprise market (and it certainly seems poised to), it could expose a lot of people to just how awesome Apple's development tools are. Shops that want to develop custom iPhone apps will have to buy some Macs, and will have to hire or train Mac-savvy developers. Like a benevolent virus, a love for Cocoa tends to be infectious, and some hands-on experience with modern Macs might just disabuse some of the Corporate IT drones of their outdates ideas about just what a Mac is. 

I've worked on projects where handheld clients to ERP applications were being implemented. Though I've never been directly involved with the mobile implementation work, I have been involved enough to see that the offerings tend to be expensive, not particularly intuitive or easy to use, and often require you to hire the vendor's consultants if you've customized your system at all (and everybody customizes their system). In my experience, I can't recall having seen a mobile client to an ERP application whose functionality couldn't be replicated in a couple of days for the iPhone.

I would conservatively guess that a company willing to standardize on the iPhone OS and do custom development for their mobile needs could reduce the cost of their mobile implementation in half. Savings of 90% or more are absolutely not out of the question.

We do live in interesting times.




Saturday, March 15, 2008

Still Playing

I started working with the audio toolbox on the iPhone today. This morning, I added sounds to the little dice rolling application I've been writing. I recorded a total of fifteen sounds, five of a single die being rolled, five of two dice being rolled, and five of four dice being rolled. I let my kids roll the dice while I recorded the sounds, which they thought was cool, although they can't understand why I can't put the program on my iPhone. 

Do you hear that, Steve Jobs? You are making my kids sad. Do you really want that on your conscience?  ;) 

Unfortunately, the "Coding How-Tos" on the iPhone web site don't give a full code sample on how to play audio files. They show the command to play a sound, but not how to find and load the file from your application bundle (it may be in the how-tos somewhere, but it wasn't under the section on playing audio). Figuring that out took a little poking around in the documentation and header files (and, of course, a couple of application crashes), but I got it working without too much trouble. 

Boy, it's been a while since I've worked with pointers... I spent way too long working almost exclusively with Java. I don't want to bash Java - I know a lot of people like it, and it's been the basis for a lot of my income over the years - but it just feels so much less elegant than objective-C. 

Since I wrote my first AppleScript Basic program in 1980, I have used literally dozens of different programming and scripting languages, many extensively and as part of my professional life, and I can say that Objective-C and Cocoa (and now Cocoa Touch) are, by far and without a doubt my favorite. They take a little while to understand when you first start using them, but once you get over the "grokking curve" and really start to understand how it all pieces together, coding in objective-C really becomes a pleasurable experience. It's just plain fun. 

In a way, I envy all those people coming to the iPhone from other languages and toolset. They are about to discover something very, very cool if they have the patience to get past the initial obstacles.




Friday, March 14, 2008

A Splash of Cold Water

I would imagine I'm not the only person who received notification from Apple today that I'm not accepted into the first round of iPhone developers. I understand that they're probably giving priority to their more prominent development partners and that they don't have the resources to support everyone, but boy, it's a tough pill to swallow. Especially since Apple is so quick to publish press releases lauding just how many people have downloaded the SDK; they never make mention in those press releases of the fact that not everyone who downloads it will actually get to it fully.

Frankly, I'm not that all that irked about not getting access to the App Store. I'd like to have that option available to me, but what I really, really, really want is to be able to test my apps on an actual iPhone. I bought a new iPhone last Thursday with its own phone line just so that I would have one that I could install the 2.0 OS onto without fear of screwing up my main phone. And now, I can't use it for that purpose and don't know when I will be able to.

I'm bummed.



Daring Fireball on "One App at a Time"

John Gruber, Mac blogger extraordinaire, has a post today about what I consider to be the most glaring problem with the iPhone SDK. I don't know John, but I rarely disagree with him on matters related to Apple, but although I think he makes good points about WHY Apple chose to put this limitation on the SDK, I disagree that Apple should be the one making this choice. If a user wants to put a program on their iPhone that will reduce their battery life, that should be their choice. Apple is requiring all apps to be reviewed, so in theory, an app that went overboard or impacted the network would be stopped by them in their role as App Store gatekeeper.

There are many, many potential killer apps for the iPhone that simply can't be created without some way of running code in the background. If they can't allow this, then there should be some alternative available. Maybe there is, and it's buried in the SDK somewhere, but I haven't found it, and I've been looking pretty hard since last Thursday.

Apple obviously recognizes the need for this, since they do it themselves in Mail. It seems pretty obnoxious to say "yeah, we need to do this, but you can't. Ever." Yeah, I know it's their phone, and they can pretty much do anything because they wrote the software that runs it, but I think this limitation is potentially devastating in terms of the iPhone reaching its full potential as a "mobile platform", especially one that Apple seems to be positioning for a push into the Enterprise market.

It seems there must be a way to address their concerns, and yet make it possible for apps to do things when they are not being run.



An iPhone App

I really hate the chilling effect the NDA is having on the iPhone developer community right now. There is no mailing list where we can talk tech about this, or ask others for feedback, and we have been admonished not to talk about it even on Apple's official Cocoa-dev mailing list, where developers turn to each other for help with coding problems.

I understand, to some extent, why Apple is doing this, but given the fact that any Schmoe can sign up for an ADC free membership and moments later download the SDK, it seems a little overkill. I would fully agree and understand this if, like most pre-release software, the SDK was seeded only to Select and Premiere members of ADC, but since it's not, it's bordering on silly. It's like putting a notice on a bulletin board and then asking people not to talk about it. Except that Apple has a means of enforcing this edict, and it's one smart developers are not going to risk facing, since it will have a pronounced affect on their bottom line.

I may not be able to share the code or write a tutorial about how I did it, but I certainly can show you a screenshot of the little app I hacked out last night. This took me about two hours: a little less than one hour for the code, and a little more than an hour to take the pictures of the dice, crop and resize the photos, and make the icons.





Developer Certs and iPhone OS 2.0

One of the things that seems to be causing a lot of  iPhone developers grief at the moment is figuring out how to get the iPhone applications they are creating to run on the iPhone rather than on the simulator that comes with the SDK. This issue has annoyed me as well, so I've spent some time trying to get to the bottom of what one has to do.  I thought I'd take a second to explain the situation as I understand it. Now, this isn't official, I'm just telling what I've been able to glean from reading, experimenting, and talking with people. It could be wrong, but I don't think I am.


One that Apple states is that you need a developer certificate to run an application on an iPhone. The documentations goes so far as to tell you how to create one, but there is currently no way to upload one to ADC. You can't upload one until you've been accepted as an iPhone developer, and so far, I haven't heard of anybody who's been notified that they've been accepted. It's possible that some people have, but everyone I've talked to is still anxiously waiting.

But more important than the developer certificate is the fact that Apple hasn't released the 2.0 beta version of the iPhone software which is needed to run third party apps. In other words, even if we had our certificates, we couldn't actually do anything with them at the moment because our phones need to be updated to run these apps.  Rumor says the beta version is going to be released very soon, but there's no official word out of Apple about it yet.

Unfortunately, the bottom line right now is that we have to be patient.




Thursday, March 13, 2008

Good Googly Moogly! 100,000 downloads

Ars Technica is running an article claiming that the iPhone SDK has been downloaded 100,000 times! I knew there was excitement in the air over this thing, but holy cow.



On Censorship and the iPhone Application Store

One of the complaints I've heard from many people about Apple's approach with the iPhone SDK is that they have retained an awful lot of control over what developers can do with it. You have to be approved by Apple to get a developer certificate, all your code must be signed with that code certificate to run,and your applications must be reviewed by Apple before they can be sold.


While I understand why Apple is doing this (sort of),  I still think it's a valid concern on the part of us developers. This is a "Big Brother" level of control that Apple is demanding over us, and I think it's going to stifle development and annoy some of the most stalwart supporters of the company. I don't think people will refuse to develop for the iPhone as a result, simply because the iPhone has such huge potential and offers a rare opportunity to be part of an emerging market, but I do think it will have a negative impact.

I certainly understand Apple's stance against malicious applications. What I don't understand is why Apple is including content restrictions. Why is Apple requiring iPhone applications to be family friendly, but yet is currently selling thousands and thousands of songs with explicit lyrics, and movies with nudity. Why can they peddle Natalie Portman's naked derriere on iTMS, but the same content as part of an iPhone application would be inappropriate? Or would it? 

And that's the big issue I have: it's arbitrary. There are no guidelines for developer to follow, no parameters defining what really is okay and what is not. Apple could simply say "no" for no good reason, or even to stifle competition the way Microsoft is known to do. I'm not saying they will, and I hope they don't, but they've given themselves that much lattitude. 

The restrictions against "illegal" and "malicious" software I understand, as well as the restrictions on those that use too much bandwidth or have privacy implications. But "porn" and "unforeseen" are both incredibly vague categories and basically say "whatever we don't want to let you put on there".  Certainly, my idea of what constitutes porn and for example, James Dobson's idea are probably radically different.

I have no problem with certain constraints being placed on me in exchange for getting ready access to iPhone users, but I want to know what those limitations are before I invest countless hours in developing an application.




Wednesday, March 12, 2008

I Love Mac Developers

I mean that in all sincerity. They really are a diverse and interesting lot, and for the most part, very smart. Most of the people blogging iPhone development right now are from the Mac development community, which makes sense. Since the iPhone SDK is so similar to Cocoa, so these folks have a leg up. 


I haven't been actively participating in Cocoa or Objective-C circles for close to two years, but the release of the iPhone SDK has pulled me back in. It is very refreshing to be immersing back into it.  This is a great and really helpful group of people. Almost every time I've ever had a Cocoa problem that I couldn't resolve myself after researching, I found someone on Apple's Coco-Dev mailing list who would point me in the right direction. It's better tech support than most companies provide their paying customers. It is a community. Now, I know that word gets thrown out a lot with respect to the internet, but in most cases, it's misapplied. Not so for the Cocoa development community.

Anyway, studying the iPhone SDK documentation, I started looking for information on how much memory was in the phone, and how much as available for your application to use. I'm not talking about the widely touted 8 and 16 gigs of persistent flash memory in the phone, but the amount of volatile physical memory. It turns out finding this information is not straightforward at all: Apple does not include this information in the iPhone specs page nor could I find it any an of the SDK documentation. I broadened my search out to the interwebs, which led me to Craig Hockenberry's blog and more specifically this entry. It didn't take long for some smart person (aka Craig, in this particular case) to identify the hole in the documentation and plug it. He could have kept this information to himself, giving him a leg up on a great many developers, but instead, he chose to share it.  For those of you who didn't click the link, the answer I was looking or is that the iPhone has 128 megs of RAM, with 64 being available to a running application.

Of course, once I found Craig's blog, I started reading through the entries. I did this partly because I like the way he writes, but also because part of my (second) job right now is to find out everything I can about the iPhone and the iPhone SDK, and Craig certainly seems to be knowledgeable in this regard. I must say, though I don't know Craig personally, I'm rapidly becoming a fan of his. I especially like this post where he suggests raising the barrier to entry for iPhone development by charging $499 instead of $99 to become an iPhone developer. I know this probably will not prove to be a popular opinion, but it's one I agree with, although I would propose a slightly different approach. Instead of raising the price substantially for becoming an iPhone developer, instead, simply don't make it an option for ADC Free members. 




Tuesday, March 11, 2008

Rogue Amoeba

Paul over at Rogue Amoeba has an interesting post on the "Under the Microscope" blog. It's a list of defect reports that people at Rogue Amoeba have filed about limitations with the iPhone SDK that they feel are unreasonable. This is the right way to let Apple know; they do listen, especially if they hear the same thing from a lot of people. So, if you agree with any of his points, make sure you open a defect: There is power in numbers. 

A few of the defects that Paul lists, I happen to agree very passionately with. A few others I really don't have much of an opinion about simply because I just can't seem them impacting my ability to develop the apps I want to develop, or to use the phone the way I want.

There are a few others where, even though I might agree personally, I think that they are just tilting at windmills; AT&T, for example, is not going to allow VOIP applications on EDGE if they have any way of stopping it. And, let's face it, it is their network, like it or not. A VOIP app would let people use their unlimited data minutes instead of their limited pool of voice minutes to make phone calls, meaning nobody would ever bother paying for their more expensive plans. Corporations exist to make money; AT&T is never going to let this one go without a fight.

Now, a few years from now when the iPhone is no longer exclusive to AT&T, and it's a well-established platform with a thriving developer community, that will be the time to try and shrug off these particular shackles, but not now. I'm sure this is not just Apple being arbitrary; I am sure they have specific things in their contact with AT&T that they simply can't do on the iPhone, as well as things that they can't allow others to do.

I'm sure Apple is being cautious also because they are relatively new to the mobile space, and they do not want the bad publicity of being blamed for, say, bringing down AT&T's network with something that they did or allowed to be done. They certainly do not want to see headlines about iPhone viruses hit the wire. In this market, Apple has more naysayers than they do in the computing world, and they have plenty of naysayers in the computing world. 

For my own part, I would love a completely open system, but I understand that the practical realities of the situation just isn't going to allow it now. Just like Apple to agree to use DRM on all tracks on the iTMS at first, I'm sure Apple had to agree to certain distasteful terms with AT&T in order to get their foot in the door in the competitive and highly regulated cellular phone market, and on those turns, developers can yell and stamp their feet as much as they want, but Apple's not going to budge.

Here are, the issues he mentions that I will be opening my own defects for: 

Allow applications to be installed at the user's discretion, not Apples

I'm not really hopeful about this one, but I do agree with it. You pay $400 or more for your iPhone. You own it. You should get to choose what you install on it, without having Apple, Inc. playing Big Brother.  The fact is, the iPhone is already jailbroken so people who want to write malware are not likely going to use the official SDK anyway. As a result, there's really no good reason for maintaining this insane level of control over what third party developers do.

On the other hand, I'm not going to refuse to develop for the iPhone simply because of this.
Allow applications to run in background on iPhone
Oh, yeah. This one really is a make-or-break item in my mind. Without the ability to at least run a small helper daemon. Many of the ideas for killer apps simply can't be done. Several of my ideas hinge on finding SOME way of running code when my application is not open. Apple does this with mail and calender, so there's no technical reason to disallow it and they're setting a very obvious double-standard here. I'm sure they're concerned about what people might do with the ability to run background apps, but since apps have to be approved to go on the iPhone App Store, and the platform was jailbroken months ago, this would seem to be a completely overzealous restriction. 

Allow iPhone applications to access the docking port.

Just like with background processes, Apple does this with a good chunk of their applications, but they won't provide a mechanism for doing it other than doing network communications, requiring a server application running on the host. This one is patently ridiculous as well. We should not have to jump through hoops to communicate with the host computer.

Several of the others he mentions are things that I would like to see, but these three are the ones that will have the most impact on my work. The inability to do background processing is the one that will hurt me the most personally (by far), as most of the ideas I'm working on require at least some ability to do things when my application is not being run.

While I personally would like root access to my iPhone, I don't see it happening, and don't see that most users and most apps need it. VOIP would be cool, but I'm not much of a talker, and doubt I'll even come close to using my 400 minutes of talk time most months, so having a free way to spend more than 400 minutes a month talking on my phone is not really a big draw for me.




And We're Off...

Last Thursday, Apple announced the iPhone SDK (that's Software Development Kit for you non-techies), and I promptly signed up for developer status. In doing so, I have to comply with an NDA (non-disclosure agreement), so you won't be finding any technical details or code samples in this blog until at least June, but I am going to start writing my high-level impressions of what it's like to develop for the iPhone as I work through it.

I spent the last weekend chugging through over a thousand pages of technical documentation on the iPhone and the iPhone SDK, as well as writing some fairly simple iPhone applications in order to get a feel for the platform. I must admit that I am seriously excited. This is one heck of a mobile platform.

The funny thing is, I've never been excited about "smart phones" before. Not in the slightest. I never cared for Blackberries or Pocket PCs, seeing them always as a way to be further chained to work and nothing more. In my travels, I've met far too many people in the IT world who are slaves to their mobile devices — they don't like them, but feel like they need them. For my purposes, I've always just wanted a phone. A small, tough, easy to use phone. I never wanted a camera in it, I never used the date book or other little tools because, frankly, they were far more trouble then they were worth.

And though I must admit that I experienced a certain amount of techno-lust for the iPhone, I resisted buying one, mostly because I was under a contract with Verizon and I've been fairly happy with Verizon's service. If the iPhone had been available through Verizon, I suspect that I might have bought one the day they came out. As it was, that additional barrier allowed me to accomplish the herculean task of resisting its allure.

Last year, at WWDC, when Steve Jobs announced that sure, we developers all could write applications for the iPhone right away.... by creating web applications, I honestly felt like he had kicked me in the gut. Here, they  had created this amazing, possibly revolutionary new device, and they wouldn't give us developers an opportunity to really help them realize its potential. There was an audible groan when he made this announcement, something that rarely happens inside the RDF

Not too long afterwards, Apple started hinting that a real SDK might be forthcoming, and then later confirmed that it would be.

Needless to say, I have been awaiting Thursday's announcement very anxiously. This time, I was not disappointed. In fact, they exceeded my expectations: I ran right out after watching the videocast and bought myself an iPhone, downloaded the SDK, and started pouring through the pages and pages of really solid technical documentation already available from Apple.

And, though I can't tell you specifics because of the NDA, I can tell you that it is a thing of beauty. It really is. It is an elegant set of tools and libraries and I'm just giddy with excitement over this darn phone. I honestly think that the SDK has the possibility of completely changing people's perception of what a mobile device is, and what a mobile device can do. Some would argue that the iPhone has already done that, but I think the best is yet to come. I believe the iPhone can, and will, replace many special-purpose devices and become, as I heard one geek say, paraphrasing Tolkein, "the One Phone". Sure it was forged not in the fires of Mount Doom by Sauron, but rather in Cupertino by the will of Steve Jobs and the brains of an awful lot of very smart people, but I still think it's an apt analogy.

Several times a day a new idea will hit me for an iPhone app. I haven't been this excited since I discovered Cocoa / Objective C eight years go.