Skip to main content

Standalone Web Apps on iOS

As more and more mobile OSes are released, that means apps have to developed for more and more platforms; multiplying the workload and the cost to both create and maintain any mobile app that you want to be available to anyone.

Luckily, the web offers us a more standardized platform. (And before you cite differences in browsers: browsers are free and much easier to change than hardware, and there may be some minor discrepancies but the base technology used for development is still the same across the board).

While there are obvious drawbacks (available data connection, bandwidth, integration with device-level features), many of those do not have that great of an impact for a lot of applications or can be circumvented with HTML5 APIs.

One hurdle that HTML5 doesn't solve (at least, not that I've seen) is to run a web app in a way that the user experience is the same as if they were running a native app; meaning the removal of the browser chrome (address bar, browser menu, etc; Not to be confused with the Google Chrome browser!).

While it may still be a device/vendor-specific solution: Apple offers us a simple mechanism to accomplish this.

From Safari, users can choose the "Add To Home Screen" option to bookmark your site to an icon on their home screen. When they then load the site by tapping this icon, with the right code on your page, it will run in standalone mode and appear to your users to be a native app.

To achieve this affect, just add the following meta tag to the head section of your HTML:

Then, on your page, you can detect if it's running in standalone mode with the following javascript: 

if (window.navigator.standalone) {
  /* app is running in standalone */
}else{
  /* app is running in the browser, or on a system that doesn't support the standalone flag */
}

You can specify a file using the following file names (just include them in the same folder as your web app). If the files aren't found, a screenshot of the web page will be used instead.

(exerpt: Everything you always wanted to know about touch icons)
  • apple-touch-icon-57x57-precomposed.png or apple-touch-icon-57x57.png for non-Retina iPhone and iPod Touch
  • apple-touch-icon-72x72-precomposed.png or apple-touch-icon-72x72.png for the first- and second-generation iPad
  • apple-touch-icon-114x114-precomposed.png or apple-touch-icon-114x114.png for iPhone 4+ (with Retina Display)
  • apple-touch-icon-144x144-precomposed.png or apple-touch-icon-144x144.png for iPad 3+ (with Retina Display)
  • apple-touch-icon-precomposed.png and apple-touch-icon.png as a fallback for everything else (possibly including non-Apple devices)
Labels:

Comments

Post a Comment

Popular posts from this blog

SASS Converts Zero Opacity 'rgba' To 'transparent'

I recently had a strange problem after updating SASS. I have a modal dialog with a semi-transparent overlay behind it. For modern browsers, I'm using a CSS transition from rgba(0,0,0,0) to rgba(0,0,0,.5) For older browsers (namely IE8), I'm using some JavaScript to apply the transparency and animate the transition. To make sure the background gets set correctly, I'm using the standard fallback strategy of defining the background as background: rgb(0,0,0); right before the rgba line. This worked fine, until SASS optimized my code by changing background: rgba(0,0,0,0); to background: transparent; The reason? It's 2 characters shorter. Yes, we've now saved 2 bytes of easily compressible text in exchange for breaking my code. Why did it break? Well, if you haven't already figured it out, normally a browser that doesn't support rgba will simply skip that property and move on. But transparent is supported. So now, instead of h...
Post a Comment
Read more

Automatically Calculating Foreground Color using SASS

I ran into the problem, as I'm sure many others have, where I wanted to dynamically assign background colors to my components, but also needed to adjust the foreground color to be readable and visually appealing. It's easy for something to fall through the cracks when changing colors, and then we end up with unreadable text. So to try and avoid this, I put together a SASS function that selects a color for text based on the background color you give it. This also performs checks to make sure the contrast meets a given Accessibility spec (as per W3C rules). So far I've had pretty good results with it. Please feel free to tinker and use this in your own projects. It's far from perfect, but it has See the Pen Calculate Foreground Color by Thomas Pietrosanti ( @Rykus0 ) on CodePen .
Post a Comment
Read more

Element.focus() in IE9 running Jasmine tests with Karma

I recently udpated our Jasmine unit tests to run in Karma ; expanding our browser coverage, adding code coverage reports , and using fixtures for testing DOM manipulation . One of my tests kept failing in IE9, but only when I ran from the console. If I attempted to debug in the browser, everything passed. It turns out that IE9 (at least) needed a few ms to catch it's breath before correctly focusing on the starting element. To do this, I just added a 100ms delay before each test ran (Using Jasmine 2.3). beforeEach(function(done){ loadFixtures('myfixture.html'); // Setting focus in IE requires a delay to work correctly! setTimeout(function(){ done(); }, 100); });
Post a Comment
Read more