Yesterday Paul Graham posted an essay about Apple and the iPhone dev process, along with a new Request for Startup (RFS). It’s a good read, and one of the hypothesis put forth is that developers will write software for the device that they have. Many developers have iPhone, and therefore are targeting the iPhone for development. As a result, one way to woo developers away from the iPhone ecosystem is to create a killer app for developers, and suggests that one such app may be an environment that allows developers to write code on mobile devices.
It’s good timing from my perspective. I’ve been away all week in LA at Microsoft’s Professional Developer Conference (PDC) and have been immersed in dev content. I love events like this because being surrounded by smart people and new concepts helps to stimulate my own thinking.
When thinking about mobile development, there are a few assumptions that I’m going to put forth to differentiate between a traditional IDE:
- Extremely limited screen size
- Cumbersome to enter text
- Low client-side processing power
Of course, you could just get around these constraints by connecting to a mouse, keyboard, and monitor – but that’s kinda boring, so I’m going to focus on a scenario that assumes no access to peripherals.
OK, now let’s start to narrow it down a bit. First, let’s focus only on building mobile apps. There’s no reason why you couldn’t spread to web apps, but mobile apps make sense because you’re already on the device itself, which gives you a slight advantage due to the WISIWYG-iness of it all.
To start looking at how this would work, let’s walk through a simple scenario and start explaining some of the details as we go. Since I’m typing this up in the airport waiting for updates on my delayed plane to arrive (I heart LAX!), let’s say that you wanted to build an app to track the status of a specific flight.
To get started, the first thing a dev would do is to create a high-level model of the app. This would be a simple block diagram that would start by walking through the UI flow of the app. Once you had each block in place, you would drill into each block and define the type of functionality you want for each step. For example, your first screen might be a splash screen with your logo. Next would be a form that would let you enter your flight information, followed by a third page that would display the status.
Each block would be driven by customizable templates. There would be 100’s of pre-built templates available from the system, and also the option to pull in user-generated templates from the community. For our example, the first block would be a “Splash Screen” template. Once you choose the template, you then walk through a simple wizard to modify the template. Again, for this example, the wizard would ask for the image that you would want displayed on the splash screen. When you’re finished, the system would do all the work on the back end to turn it into a fully-functioning splash screen for your app.
Once you have the UI elements in place, it’s time to start wiring up the back end. This would be done using a similar model-based approach to build out a high-level abstraction of the program’s functionality. For example, let’s look at the input form for the flight tracking example. The logic flow is roughly something like this:
- Get the airport code for the user’s starting and ending destination
- Hit a web service to look for all flights to/from those locations over the next 12 hours
- If there are multiple flights, let the user pick the correct flight
- Send the flight info to a web service and pull back the flight status
- Pass the flight status to the display page and give up control
One of the keys to making this work is to rely very heavily on the ability to package up very common mobile development tasks into small snippets of code. As devs work through the logic for their app, the goal is to break down the elements of work into smaller and smaller pieces until you get down to something that can be represented by a short, common snippet of code.
Of course, the code could be modified once it’s in place, but by starting with a rough framework, we solve two problems. One, it would significantly reduce the amount of typing. Two, it would enable the developer to spend more time simply modifying code instead of having to switch over to a browser to look up syntax or do a search/copy/paste.
The revenue model would be similar to Weebly, where users could build one app for free, and could build additional apps for a small fee. Another potential revenue possibility is to automatically submit the apps to the app store and tack a small “service fee” on top of the standard submission cost.
There’s a lot more to this idea, but this post is already getting a bit long so I’m going to call it. To stay updated on my latest ideas, you should follow me at @astartupaday on Twitter.