The “Smart App Banner” feature in iOS 6 promises to let you pimp your app without the ugly splash screens that drive people so nuts (especially for freaking content sites…. looking at you The Verge, and ABC):

Ugh, I just want to read your content! Anyway, back to the smart app banners. I was very curious to play with them and see what kind of controls I could put in place.

It all comes down to:

<meta name="apple-itunes-app" content="app-id=myAppStoreID, affiliate-data=myAffiliateData, app-argument=myURL">

The good news:

• Since iOS is in charge of what to show, the area “trusted” (how long until people fake it out?)
• If the application is unavailable (device / OS doesn’t support it, or in the wrong region), it won’t be shown
• The system knows if the app is installed (wouldn’t want to tell the web site… privacy an all) so it can flip the action from install to open
• You can pass a “URL” as an argument (app-argument), meaning you can give the site deep link ability. In our case, we can pass walmart://product?id=X on a product details page, and when if you open the app it can display the product.
• Affiliate info can be passed in (affiliate-data).
• I wanted to see if I could dynamically add the meta tag, and that works fine.

The bad news:

• I would like to be able to say “If the user has the app installed already, don’t bother showing the ‘OPEN’ for this page please”. E.g. I am just trying to use this to push downloads.
• I would like to be able to say “If the user doesn’t have the app installed, don’t bother showing the ‘INSTALL’ for this page please”. E.g. I am just trying to give you a nice deep link here.
• I would like to be able to tweak the messaging and call to action. E.g. “To see rich details of this product, open in the native app”
• I would like to declare “I don’t want to bug the users, so only show the message once a month”
• I would like to declare “Place this above the view port, so it isn’t in the users face, but if the user scrolls up they will see it”
• As a developer of dynamic apps where the client does the rendering, you are severely limited. Dynamically adding the meta tag works (as stated above), but it doesn’t seem to work when I: a) change the meta tag, b) remove the meta tag. If you imagine pushState’ing around and wanting to turn off the banners, no cigar.

This feature has a ton of potential. If you want to throw a meta tag on your home page, or on the incoming page (e.g. if referrer != yourself), then you are golden. If you want to do much more… no cigar.

There have been many trends as folks shimmy between using native and Web technology for mobile. There are the extremes of pure native, or pure HTML. Then we have the world of the WebView… ranging from simple “stick in some Web Content here” to PhoneGap-esque bridge technology to bidirectionally speak between Web and native.

I have witnessed a new approach that aims to give you a compromise of “I want to be able to update the apps outside of a native update cycle” and “I have to use Web tech to do that”.

It was interesting to see that the new Facebook for iOS app use this technique:

To solve this, we came up with a different plan to let you use the newest features without requiring you to update the entire app: a “fallback” renderer. When the news feed team designs a new type of story, Facebook for iOS downloads something it doesn’t quite understand. When we detect this, we use a “fallback” renderer to show the pertinent information in the new story in a format the app already understands. In the meantime, we create a new custom renderer and have it ready for our next app update. For areas within the app where we anticipate making changes more often, we will continue to utilize HTML5 code, as we can push updates server side without requiring people to download a new version of the app.

This is a great backstop. Not only does it give you some future proofing, but it also can let you get out of jail.

For example, if I look at my Walmart apps, being able to checkout is critical to the business. If I bring this functionality to the world of native and something goes wrong, I want to be able to immediately fall back to an experience that works. This model gives me that ability.

The Web IDEs keep developing, and Google open sourced a piece of their work with Collide, which is a now open project created by the GWT team from Atlanta. Well, the former team.

Stephen Shankland has shown the link with the team that no longer exists.

The Google Atlanta team is now largely the Monetology team. As I have mentioned before, although I am personally not a “GWT kind of guy”, the team that developed it are truly top drawer and amazing engineers. They also got into the weeds to hunt out the ugly corners of browsers and showed us tricks that everyone could use (e.g. Closure Compiler and more).

Collide itself focused on the “collaborative development” side of shared coding. I don’t think this is the full breath of what they had working at Google though. I really hope that the world gets to see the full vision of the web development tools that they had put together. I have heard that it is pretty special. If Google isn’t going to use the work, maybe we can see more open sourced, and once Bruce and team revolutionize revenue generation… maybe they can switch back and get back to developers :)

I feel for the Firefox Mobile OS team the same way that I feel for someone going off on a tough road. Not even just a trip up Everest, but something you have to do. Maybe Frodo’s trek? :)

Mozilla’s mission is to “to promote openness, innovation and opportunity on the Internet.” One area of focus has to be the world of mobile, and it has been in different ways over the years. Having a great browser on iOS or Android can only get you so far though with the closed ecosystems (amazing that Windows is open!) especially iOS.

How can they find a niche in the OS space though? They have gone after the International market with Boot to Gecko and the now announced name of Firefox Mobile OS. They aren’t looking to come out on Verizon and go up against the Droids and the iPhone right away. That is a tough fight. Notice the wording in the title of the announcement (and the theme in most of the posts on the topic) “Mozilla Gains Global Support”.

The Firefox OS for mobile devices is built on Mozilla’s “Boot to Gecko project” which unlocks many of the current limitations of web development on mobile, allowing HTML5 applications to access the underlying capabilities of a phone, previously only available to native applications. Telefónica’s Digital unit joined forces with Mozilla earlier this year to take this work and showcase a new phone architecture where every phone feature (calling, messaging, games, etc.) is an HTML5 application.

Due to the optimization of the platform for entry-level smartphones and the removal of unnecessary middleware layers, mobile operators will have the ability to offer richer experiences at a range of price points including at the low end of the smartphone price range, helping to drive adoption across developing markets.

Can Mozilla win with a strategy that hits areas of the world that aren’t smartphoney yet? The business model of mobile is not the same everywhere. What if the carriers don’t subsidize phones and paying for a full price iPhone is a few months wage? Can Android own that market though?

From my Palm days I remember the carriers REALLY wanting a third player, but there is only so much they do. Being able to easily customize the experience “by changing a web page” is technically powerful, but is it enough compared to the massive app ecosystems elsewhere?

Then there is the “it will never work. The Web isn’t good enough to be the OS.” Here I disagree. A constant frustation has been people telling me that webOS’s issues were due to the Web. webOS != the Web. That being said, building a mobile operating system that consistently responds as well as the top competition and also handles the battery well (the other side of the coin) is hard work. Long toil work, not sexy work. It takes time and blood.

So, Mozilla has a long trek ahead of itself. Fortunately they have their mission by their side, and resources to take the long road to get there. I will be brutal here, but I haven’t thought that Firefox was competitive with Chrome/Safari wrt Mac performance… but with the latest versions I have been shocked. They pulled it off. Apart from scrolling (which is far from smooth for me) the beast is frigging fast. And I give them massive kudos for pulling that all back. Remember, they had to do so back from using XUL. I am sure much blood was shed there, and I look forward to seeing them fight on mobile.

Our Web may be ugly, as democracies are, but the dictatorship won’t work in the long run. Even if you have the best king in the world, what happens when he dies?

• Is it their rendering engine?
• I don’t see how it can be v8 (can’t write a JIT)
• Did they do some kind of deal with Apple to get the exec bit turned on so they would at least get a Nitro boost?

Nada. Just a “chrome” around UIWebView that is 2 to 3x slower at pure JavaScript. This isn’t the be all and end all for performance, and they can still pull out some tricks to give you an enhanced perceived performance (more agressive preloading etc), but it is hard to use a browser when you know it is crippled. The UX has some nice touches (and gestures), but it has also been strange for me to get used to the URL bar always on the top (even though it gives you more room as their is no need for the bottom toolbar). I bet I would get used to that. I also found that I would get false positives on edge swipes. Having access to my shared history + passwords etc is a great feature, and the tab management is much nicer than Safari, but all in all I think it gets relegated to the “browsers” folder with Dolphin and friends.

I look forward to some healthy competition, and I really hope that we get to a world where we really get to see Chrome shine. I want v8, Chrome APIs, and all of its goodness. I was hoping that some changes to the app store guidelines would enable some of that, and I hope that in the future we have a chance at the v8 piece.

And then there is the ChromeWebView dream.

We saw mobile Web developers rejoice at the news that Chrome is the default browser for Jelly Bean, although it is only on some devices (so far Nexus 7, not on the Galaxy Nexus).

For Android to rise the steps to the land of developer happiness I think that we would like to see more steps:

• Make Chrome default all over (darn OEMs get in the way I know)
• Make Chrome the power of the WebView (and update the WebView API itself to be richer)
• Have Chrome update itself independently of the OS updates
• Have the WebView able to update itself
• Have the WebView versioned so apps can target it?
• And then the mother-lode: Have a Chrome WebView that you can take to other platforms too :)

What would you like to see?

Today we see two new releases in the Web based editor space that make me smile.

Cloud9 IDE launches with a couple of very important features. The biggest one is collaboration:

You can now collaborate on your code with real-time co-editing and embedded chat. Pair programming, code reviews, going to a conference and teaching a group of students the art of programming – everything about the way we code together will never be the same again.

One of the things we wanted to do was to have open collaboration sessions so you could sit and watch Brendan Eich hack on JavaScript and the like :)

Adobe Brackets has a fantastic UI and focuses more on the designer world. The world of the live preview. It is also satisfying to see Adobe take this on, and the manner of which they are doing so (in the open), especially given some chats that we had in the Bespin days :)

• Tools shouldn’t get in your way. Instead of cluttering up your coding environment with lots of panels and icons, the Quick Edit UI in Brackets puts context-specific code and tools inline.
• Brackets is in sync with your browser. With Live Development, Brackets works directly with your browser to push code edits instantly, set breakpoints, and jump back and forth between your real source code and the browser view.
• Do it yourself. Because Brackets is open source, and built with HTML, CSS and JavaScript, you can help build the best code editor for the web.

But Web based coding tools aren’t the only ones that are innovating. Sublime Text 2 is moving fast and where I used to see Textmate, I now see Sublime.

We could get away with this when we were sprinkling Ajax dust into web pages via jQuery, but as soon as you get larger, you find yourself building some kind of dependency / package management system. The community has certainly offered up a lot of choice in that regard, and with CommonJS and node… along came many more.

Now that JavaScript is evolving again (once Harmony was reached) we can look to attack the problem head on and TC-39 is doing just that with their Module work.

Isaac has just written an interesting piece on ES6 modules from his perspective (which is an important one having creating npm and now leading node.js).

He first takes a look at the issues with loaders in the wild, and then offers up a potential solution…. which interestingly doesn’t have a module formal keyword.

The current implementations:

• Impose boilerplate restrictions on the programmer. This is ugly and error-prone, and there is no easy way to catch many of these errors early.
• Are not inter-operable with code that uses a different module system (or none at all).
• Either require that all modules be present in the page at the start, or delay the execution of the program unacceptably. (No one does sync XHR. I’m talking about r.js/AMD and the YUI3 seed file here.)
• Leaks internal implementation details in unfortunate ways, so that users are sometimes surprised when behavior violates intuitions.
• Do not isolate global leakage, making a missing var a felony, when it shouldn’t even be a misdemeanor. (At best, they wrap in a function.)
• To varying degrees, line and column numbers are obscured. (Sometimes just the first line’s column; sometimes the stack traces are completely meaningless.)

These days JavaScript isn’t just about a browser, but at the same time it is the only viable option inside the browser. We need to take care at how we codify modules as we will be stuck with the implications for a long time to come. We need to get it right.

It is incredibly agrevating to see “when password rules go wild”:

• Rules are so complex that you need twenty tries to get one through (and end up with a simpler password as you try to match the rules)
• Not allowed to use characters such as space, so you can’t use a passphrase which is actually more secure (password length!)
• Unable to paste a password which makes you curse since you use 1Password or Lastpass or ….

At this point I almost wish there were password standards so you could see “ok, this site is sane, they use Sanity-A.”

Want to add a sane “choose password” component? There are many, but complexify is a good new one:

Complexify’s default settings will enforce a minimum level of complexity that would mean brute-forcing should take ~600 years on a commodity desktop machine. The ‘perfect’ password used to scale the complexity percentage would take 3×10^33 years. These are equivalent to a 12 character password with uppercase, lowercase and numbers included, and a 25 character password with uppercase, lowercase, numbers and a wide range of punctuation.

Of course, you can also look into supporting BrowserID and OAuth-iness.

Santosh Rajan loves JavaScript and macros. He wanted to merge those two worlds and he ended up at an interesting well trodden place. The magical world of Liiiiisp!

He has created LispyScript, which allows you to write your JavaScript in a Lisp-like syntax. With the tree based structure you can write macros to change the tree before it is all serialized out as JavaScript.

This is the same old JavaScript object model. You aren’t in the world of car and cdr, this is the minimal amount of work to get to macros.

See it in action:

// All Javascript functions, objects and literals can be used in LispyScript. 
(Array.prototype.forEach.call [1, 2, 3]
  (function (elem index list)
    (console.log elem)))

// You can access object methods and properties using the "." notation.
(console.log (.greet {greet: "hello"}))

// You can also use the 'get' expression to access a property of an object.
(console.log (get "greet" {greet: "hello"}))
(console.log (get 1 [1, 2, 3]))

// You can 'set' variables too.
(set window.onload (function () (alert "Page Loaded")))

// Now let us create a Lisp like 'let' macro in LispyScript.
(macro let (names vals rest...)
  ((function ~names ~rest...) ~@vals))

(let (name email tel) ("John" "john@example.org" "555-555-5555")
  (console.log name)
  (console.log email)
  (console.log tel))

This all comes down to: do you want to write your JavaScript in Lisp to gain the benefit of macros. It is early work (MIT licensed) and Santosh is looking for help!