The Shape of Mobile Development To Come(clayallsopp.com)
clayallsopp.com
The Shape of Mobile Development To Come
http://clayallsopp.com/posts/the-shape-of-mobile-development-to-come/
18 comments
The problem with write once run anywhere is that it's not desirable to device manufacturers apart from those on the bottom rungs who don't have a big enough developer community to carry the devices on their own. If MS and Apple threw JVMs onto their devices then we would be 90% of the way there already.
If any write-once-run-anywhere solution becomes to popular then the likes of MS or Apple will try their best to kill it. See: Embrace, extend , extinguish by MS on Java and to an extent the web itself and Apple's ban on language runtimes/interpreters on the app store.
If every device allows for the same functionality as other devices due to identical software then manufacturers will only be able to compete on price.
If any write-once-run-anywhere solution becomes to popular then the likes of MS or Apple will try their best to kill it. See: Embrace, extend , extinguish by MS on Java and to an extent the web itself and Apple's ban on language runtimes/interpreters on the app store.
If every device allows for the same functionality as other devices due to identical software then manufacturers will only be able to compete on price.
> If MS and Apple threw JVMs onto their devices then we would be 90% of the way there already.
As a one-time proponent of write-once-run-anywhere solutions, I would have to say this would probably result in a reduction of UX quality.
As a one-time proponent of write-once-run-anywhere solutions, I would have to say this would probably result in a reduction of UX quality.
I think the MonoTouch guys are handling this in the only sensible way. Non-UI code is shared across platforms but UI code is written per-platform using the native toolkit. I think this is about as close as you're going to get without compromising user experience.
That is indeed the only sensible way.
Imagine writing code like this and having it build to native apps on both platforms:
I think Xamarin are going to be a really interesting company to watch for this stuff. Right now they have MonoTouch and MonoDroid as entirely separate products, allowing you to make apps using C#. But you can already reference libraries across both, and just do the UI plumbing separately, and if they're smart they will work very hard on what the author is describing.
I think Xamarin are going to be a really interesting company to watch for this stuff. Right now they have MonoTouch and MonoDroid as entirely separate products, allowing you to make apps using C#. But you can already reference libraries across both, and just do the UI plumbing separately, and if they're smart they will work very hard on what the author is describing.
I agree. Xamarin is closer than anybody else to a viable cross platform solution. They're in just the right place now to start eliminating some of the worst pain points in mobile.
Appcelerator ought to be as well (with the added bonus of using JS, far better known than C#), but their platform isn't on the same level. Yet?
Haven't tried it myself but the reviews on the web seem to be almost universally bad whereas most Monotouch users seem to be pretty happy. I think for larger code bases C# has some important advantages over JS.
Absolutely. I used Appcelerator a long time ago and it was awful- they've actually made a ton of progress since then, but they don't make fully native apps- there's a JS engine in the middle that parses the code. So it's always going to be a little slower than native- but probably acceptable for a ton of apps.
I've been doing this for a long time now, probably for the 8-10 months, and I can safely say its awesome. Xamarin is awesome.
I agree with your true write-once-run-everywhere dream, but I disagree with the conclusion that we build an abstraction over existing frameworks. This is essentially what wxWidgets or QT is for desktop.
While these things were great, in the end what most of us wanted was actually HTML/CSS/JS and the freedom to create beautiful things that it gives us. I would argue that default looking iOS apps are already stale and we want more control (which CSS is great at giving). I am banking my business on the same thing happening long term in mobile.
I agree that webview apps can't compete with native in certain situations, but devices are becoming more powerful every day and web technologies have already proven themselves with a large developer audience.
Also, I think there is low-hanging fruit just in the mobile web space: making more websites work well on mobile devices.
While these things were great, in the end what most of us wanted was actually HTML/CSS/JS and the freedom to create beautiful things that it gives us. I would argue that default looking iOS apps are already stale and we want more control (which CSS is great at giving). I am banking my business on the same thing happening long term in mobile.
I agree that webview apps can't compete with native in certain situations, but devices are becoming more powerful every day and web technologies have already proven themselves with a large developer audience.
Also, I think there is low-hanging fruit just in the mobile web space: making more websites work well on mobile devices.
Until mobile phones become a lot faster and carry more storage and bandwidth becomes a lot cheaper and more ubiquitous, I believe the most successful approaches simply adapts the underlying framework for use with other languages (and abstraction levels), while simultaneously minimizing the excess baggage/payload required to get a small application up and running. Clojure for Android for instance suffers from this problem (1.7 MB payload), while Scala, Mirah (Ruby-like) and Kawa (Lisp/Scheme) seems to do a decent job on providing thinner wrappers on the host platform. I see the same thing on the web as well, with a multitude of languages targeting javascript as the platform. I did a small writeup on "Android development without Java" on http://kjeldahl.net/d7/node/32 if you want more details than I wrote here.
Are there any languages that directly target Dalvik/dex without compiling through Java bytecode?
The idea that we'll be able to write apps in an interpereted language is probably a long ways off, but the second idea about more portable object models is spot on.
I would argue that such a model would need to include the ability to easily manage per record image assets. (think about how often we have images in a table view cell)
To that end, I've created an iOS library to deal with downloading these tables and images in a reasonable way. If you're interested: https://github.com/Smartovation/STRemoteResources
I would argue that such a model would need to include the ability to easily manage per record image assets. (think about how often we have images in a table view cell)
To that end, I've created an iOS library to deal with downloading these tables and images in a reasonable way. If you're interested: https://github.com/Smartovation/STRemoteResources
The article's mention of beautifully designed mobile apps sparked a few thoughts for me. One property of mobile devices and especially smaller devices like phones is people use them frequently throughout the day in short bursts. Small wait times associated with bouncing, translating animations etc are magnified and the UIs start to feel laggy. Yesterday I purchased my first Android device and the snappy UI has been quite a nice change. This is a relatively low-end Android device. And I've been using an iPhone 4S for the past few months.
So I think the design of mobile apps will be simplified going forward. I could see moving towards simpler UIs like Craigslist. This is a major win in a variety of ways: faster UIs implies better user-experience, less computationally intensive UIs implies less drain on limited resources, and simpler UIs implies less design and development time. I love the idea of never stressing out about rounded corners, little shadow and shine marks etc. They're nice to have initially but just get old as one uses the same device/OS/apps for months on end.
So I think the design of mobile apps will be simplified going forward. I could see moving towards simpler UIs like Craigslist. This is a major win in a variety of ways: faster UIs implies better user-experience, less computationally intensive UIs implies less drain on limited resources, and simpler UIs implies less design and development time. I love the idea of never stressing out about rounded corners, little shadow and shine marks etc. They're nice to have initially but just get old as one uses the same device/OS/apps for months on end.
I disagree about the prediction for simplified Craigslist-style UIs. I don't think it will ever happen on Mobile.
Animations play a very important role in communicating to the user how to interact with the interface. Animations also give the illusion of a responsive app.
The best apps are likely built by great designers who know how to use animations effectively to communicate with the user.
Everyone else will simply try to copy the best apps along with their animations... thus, it's hard to see animations going away any time soon.
On another note, I find it surprising that yours was the only comment even mentioning design. For me, that was the most important part of the article with by far the biggest implications.
The author predicts that designers will be able to take on a portion of the client-side engineering role in the near future. If this happens, it will completely change how apps are made. It will change the workflow between designers and engineers.
The traditional model of mocking up a PSD and passing it off to an engineer will no longer be viable. Designers will just build clients and interact with APIs. This means that more and more designers will probably have to learn programming, which is a good thing for the future of mobile apps.
Animations play a very important role in communicating to the user how to interact with the interface. Animations also give the illusion of a responsive app.
The best apps are likely built by great designers who know how to use animations effectively to communicate with the user.
Everyone else will simply try to copy the best apps along with their animations... thus, it's hard to see animations going away any time soon.
On another note, I find it surprising that yours was the only comment even mentioning design. For me, that was the most important part of the article with by far the biggest implications.
The author predicts that designers will be able to take on a portion of the client-side engineering role in the near future. If this happens, it will completely change how apps are made. It will change the workflow between designers and engineers.
The traditional model of mocking up a PSD and passing it off to an engineer will no longer be viable. Designers will just build clients and interact with APIs. This means that more and more designers will probably have to learn programming, which is a good thing for the future of mobile apps.
I think you're right about animation not going away. Especially animations that help the user understand the app. However I think there's still some animations and especially some shadow, gradients and other small design touches that are overkill and can be removed w/o negatively impacting the user-experience.
QuickDialog (http://escoz.com/open-source/quickdialog).
Showing a dialog:
It's really awesome, and makes all kinds of dynamic views possible. I was skeptical at first (as I am about most cocoa libraries) but I'm pretty sold on it since I gave it a fair shot.
Showing a dialog:
NSDictionary *dataDict = @{'title':'example', 'other':'other text'};
QRootElement *root = [[QRootElement alloc] initWithJSONFile:@"file" andData:dataDict];
QuickDialogController *myDialogController = [QuickDialogController controllerForRoot:root];
[self presentModalViewController:navigation animated:YES];
{
"grouped": true,
"title": "Example QuickDialog Form",
"controllerName": "QuickDialogController",
"sections": [
{
"elements": [
{
"type": "QEntryElement",
"title": "Title",
"placeholder": "item title",
"bind": "textValue:title" },
{ "type": "QMultilineElement",
"title": "Other info",
"bind": "textValue:other" }
]
}
]
}
It's really awesome, and makes all kinds of dynamic views possible. I was skeptical at first (as I am about most cocoa libraries) but I'm pretty sold on it since I gave it a fair shot.
Ha, I actually wrote something really similar (without knowing about QD) for RubyMotion: https://github.com/clayallsopp/formotion
Ruby is better suited to this IMO (no clunky file loading), but I agree they both prove dynamic native views need more exploration
Ruby is better suited to this IMO (no clunky file loading), but I agree they both prove dynamic native views need more exploration
That looks remarkably similar. Were you also influenced by MonoTouch.Dialog, as was QuickDialog's developer?
Nope, developed it totally independently according to my needs.
I haven't seen any mention of Phone Gap (http://phonegap.com/) or Titanium (http://www.appcelerator.com/). Whats the consensus of how close either of these projects get us to a "one code base" solution to multiple platforms?
Neither does a very good job if a good UX is a concern. I haven't encountered any PhoneGap apps that feel native.
Liked your idea and will follow your developments on GitHub with an eye towards how you're going to integrate a CoreData client-side library. Besides the front-end issues you highlight, a key challenge will be synchronization: unless you don't plan to allow your users to work offline?
I agree with your hope that Rails could somehow be extended to cover this mobile use case, wish I had the chops to create a Devise+MobileAPI generator with a iOS native MongoDB-sychro engine. (Can Rails generators synthesize ObjectiveC source code?)
By the way, every time I think about doing something about this I keep an eye on the folks at Parse.com: seems like every week they're solving more and more of the backend part of this problem. And they're working on front-end libraries as well...
I agree with your hope that Rails could somehow be extended to cover this mobile use case, wish I had the chops to create a Devise+MobileAPI generator with a iOS native MongoDB-sychro engine. (Can Rails generators synthesize ObjectiveC source code?)
By the way, every time I think about doing something about this I keep an eye on the folks at Parse.com: seems like every week they're solving more and more of the backend part of this problem. And they're working on front-end libraries as well...
He lost me with his "Objective-C ...has evolved over the past two years to become an "easier" language ... "
I would argue that it has less to do with the ease of the language and instead the market effects of iOS.
I would argue that it has less to do with the ease of the language and instead the market effects of iOS.
I think you might've misinterpreted what I meant? I didn't mean to imply anything about the growth of iOS or that ObjC being just perceived as an easier language because of the growth. I trying to say that Objective-C was really criticized for its verbosity and forcing manual memory management, and Apple has made changes in direct response to those with ARC and more concise literals, which IMO makes it "easier" (espc. wrt ARC)
Also @property — first you had to declare variables and use @synthesize, then you could omit the declaration part, and no you can omit the declaration and @synthesize, @property alone is enough.
It's true. Honestly, Objective-C in its current state is far easier to pick up than JavaScript, which only gained popularity due to the market effects of browsers.
I agree with most of the point, these advance certainly benefits for the product quality. But the conclusion and the hope of "Write once run everywhere" is probably not a good bet.
It is not about problem of programming language or tools, but Java already told us the "lowest common denominator" issue you have to face when implementing abstract over different platform. When people working on abstraction, it mean they will spend less time on real devices and fine details, and this is exactly what makes or breaks user experience.
It is not about problem of programming language or tools, but Java already told us the "lowest common denominator" issue you have to face when implementing abstract over different platform. When people working on abstraction, it mean they will spend less time on real devices and fine details, and this is exactly what makes or breaks user experience.
I did some research into the currently-available toolkits that let you write one code base to create mobile apps for iOS, Android, and (maybe) other mobile operating systems. I was astounded by how many options are currently available: more than 50! I made a website to summarize my findings; see http://www.mobilechameleon.com/
The notion that business logic doesn't belong in the client is wrong because you need it when working offline. And sharing UI code is a pipe dream if you want native look and feel. (If you have a custom UI anyway like in a game, it's more feasible.) A more realistic goal is port the business logic, networking code, storage, and so on, and rewrite the UI code for each platform.
The author mentions Quora and Pocket as the only examples of hybrid apps he knows of. What about the LinkedIn app? I always thought that was a good example of a well-done hybrid app.
http://kivy.org does Ali of what you talk about using python
Edit:fix link
Edit:fix link
I hope this is titled in reference to the album "the shape of punk to come" :-)
One thing all those "let's build our app on top of 1000 layers so we can use our $favourite language"-people tend to forget is that mobile software runs on mobile devices. Which have one remarkable property: they are energy constrained. So you better write some fast, native code or your users will have trouble keeping their devices alive for one day.
I remember well the assembly language crowd making the same argument back in the eighties. Processors got faster and machines shipped with more RAM. The tipping point was reached and all of a sudden no one was writing entire programs that way.
While you wait for the tipping point, I'll be over here shipping.
Shipping slow, bloated software using a framework that is a second class citizen on any platform you decide to compile to.
That is fine. We will eat your lunch on version two.
Then hire you on a great salary because great programmers are hard to find.
Then hire you on a great salary because great programmers are hard to find.
I think RubyMotion proves that alternative languages don't need to come at a cost to performance. It's tougher to write a custom compiler like RM uses, but the end result is identical performance to normal Objective-C. "Just" write a similar compiler for Android/Dalvik and you're there ;)
Just watched the video on RubyMotion. Is this really saving much time over Objective-C? I'm saving a few lines of code, but now I have to keep compiling from Ruby to Obj-C, and get none of the benefits of XCode.
I think there's far more low-hanging fruit in making native development easier than in making web/hybrid apps feel "right". I've seen two just good hybrid implementations (Quora and Pocket), and yet I still run into defects using both.
I think the "write-once-run-everywhere" benefit of web views is disingenuous; the phrase should really go "write-once-optimize-everywhere".