unFocus Projects

Category: Commentary

  • What is a “Native” App?

    I was recently asked my opinion on what makes a “native” app, and this was my response:

    It depends on how you split that hair.

    I think it depends on what platform level (hardware, OS, etc.) the particular user of the word native thinks that word applies to. It seems many use the word to refer to the actual bytecode and whether it matches the hardware (the CPU) – but in those cases I often see the term native used with the CPU architecture in the description – such as native ARM, or not native x86. iOS apps compiled with AIR 2.6 I’d say are compiled to native ARM bytecode.

    There are other ways to parse it though – for example, it was pointed out to me that AIR for iOS apps are compiled from ABC bytecode into ARM bytecode to avoid the JIT (and Apple’s restrictions on the use of JIT), but that code still uses the virtual machine – the garbage collector, sandbox and whatnot. This gets right up to the edge of my understanding of virtual machines. But, if the use of a VM precludes an app from being called native then could .NET be native on Windows, or Dalvik apps on Android? In the case of .NET, there is even a JIT (pretty sure on that one, but not entirely so).

    Then there’s the issue of targeted API (and ABI) – if an app is compiled to run on Windows, but is running in a VM on Linux, it’s probably not native (even though it’s CPU architecture probably matches), but if it runs in WINE on Linux, is that native?

    Speaking of the Linux crowd – they parse their platforms even more granularity – Gnome apps, running on KDE are not native to some people, simply because they use a different GUI toolkit, though something running in an interpreted language like Python are native if they use the “native” GUI toolkit. Games are not subject to this line of reasoning – if it runs on Linux in OpenGL (without WINE) then it’s native.

    I even remember reading some opinions in various places that programs not written in C are not native to Linux, and programs not written in C++ are not native to Windows – despite those programs using all the same APIs, ABIs, and not running a in VM.

    So what is my opinion? As it relates to my current favorite target platform, I wouldn’t call an AIR app native – especially since it requires a 3rd party runtime to be installed separately (like on Android or desktops), and doesn’t have access to the native GUI toolkits and widgets and other OS APIs. That’s not a hard and fast opinion though, my definition of native is pretty malleable, and likely to change over time (or over the course of writing this response). I think I’d have a hard time selling the idea that a Java or AIR app is native to a client – on Android mostly because of the separate runtime requirement – and on all platforms, because of the lack of access to OS level APIs. It would feel disingenuous to call an AIR app a native app.

    AIR for iOS comes closest to being reasonably called a native app – it is compiled as a complete standalone package, and runs pretty close to the metal (being compiled to ARM code) – and most importantly doesn’t require a third party runtime to be installed separately. If AIR for iOS apps had access to the native (underlying OS platform) GUI toolkit and other APIs, I would be more comfortable calling it native, though probably still wouldn’t.

    Probably the best definition of “native” I could come up (which you still won’t get anywhere close to universal agreement on) is an app that comes out of using the platform maker’s tools to develop apps for the platform – XCode + Objective-C (and other supported languages) for OSX and iOS, Visual Studio for Windows and Windows Phone, Android SDK for Android – even using Adobe’s tools to make an AIR app makes it a “native” AIR app – where using HaXe may not count as native.

    Generally though, as much as I could, I would try not to discuss whether or not an app development tool like AIR is native at all – especially since that term is so subjective. A project needs a particular problem solved, and if I can do that with AIR (on iOS that means it doesn’t require iOS GUI elements and conventions, or other features of iOS), then that’s what I’d recommend.

    Update: AIR 3.0 closes this gap, and makes the “Native App” comparison easier because of two features; 1. Captive runtime – no more separate runtime requirement means it’s a standalone app. 2. Native Extensions – now an app has access to all the native functionality of the underlying platform. I’m comfortable calling an AIR app a Native App with AIR 3.0.

  • Frash shows Flash on iPhone can be Great (with Screenshots)

    Warning: RANT ahead

    Steve Jobs is full of crap. I could actually understand and respect a straightforward admission that the Flash Platform is a threat to Apple’s iOS business model – which is the real reason Jobs won’t let Flash on the iPhone and iPad. That’s not even a very good reason – the App Store has many compelling features on it’s own, even if Flash is in the browser, not the least of which is the easy to understand path to monitization. Performance is another issue – Flash is fast enough, faster than JS/Canvas by quite a bit, but it’s still not as fast as a native app and all it’s OpenGL goodness (among all the other great Apple APIs). Keeping Flash off iPhone (and especially CS5 iPhone apps) has nothing to do with performance, or compatibility. That’s just bunk! And nobody likes a liar.

    /rant

    Here are some screenshots to show how well many sites I’ve been involved with work in Flash on the iPhone (3GS using jailbreak and Frash).

    A quit note on the technology: this is using Frash, which is a hack (a wrapper or compatibility layer) to get the Android version of Flash Player 10.1 running inside of iOS – it has not been optimized (or even completed at this point) to run well on iOS yet, and probably will never run as well as it can on Android. A recent test app I’ve been playing with runs 50% faster on a Droid Eris, vs. the iPhone 3GS – the Eris is slower hardware, running Android 2.1. It’s also crashy, and is missing features like streaming movie support (it does work with videos embedded in a swf) – and touch events are not quite as streamlined as they are on a real Android device (hover works better on Android for example, and hot spots are easier to hit). It’s also got all the quirks of the Wii and desktop Flash Player’s “noscale” feature (on Android there is a workaround that solves this, not implemented in Frash yet).

    I just like to point that out, because some users are judging the viability of Flash on iOS/iPhone/iPad based on this hack (which is current at version 0.02), which is beyond silly.

    For anyone interested, I followed these instructions to install it on my iPhone. Note: this uses SSH and dpkg to install. If you don’t know how to reverse that, you may want to find an apt repo and use Cydia to grab this, so you can uninstall Frash when you are done playing, as it can be quite unstable.

  • End of Life for IE6

    Internet Explorer 6 is approaching its end of life! I did a quick Google search and found an “End of Life” movement calling for developers to abandon support on December 31, 2009 or January 1, 2010, but according to the Internet Explorer’s “Lifecycle Supported Service Packs” , it looks like support officially expires on July 13, 2010. Notwithstanding the 7 1/2 month difference, I’m simply happy the the end is in sight! And then I read that IE6 is covered under XP SP3 and therefor supported until 2014…

    The only way to kill Internet Explorer, is to simply stop supporting it as developers. I feel we owe it to the web in general to support the latest standard (official or defacto) and the latest browsers.

  • The Third Option for HTML Font Embedding

    In the debate over whether web browser makers should implement .eot font support for Firefox in addition to their support for .ttf files (and .otf), their is an alternative that rarely gets any mention – SVG Glyphs in an html context. This is already supported by Opera 10, Safari 4, and Google Chrome (all prerelease at the time of this post). Using SVG Glyphs this way addresses a number of concerns, which are not often mentioned, or simply not well understood.

    This gets sticky, but to understand the need for SVG glyphs you need to understand the debate around DRM. DRM doesn’t work. It’s such a failure, that Apple and others have completely abandoned it in their music formats, and game companies are starting to do the same. The reality is that if the crackers and pirates can get their hands on the material (like an encrypted music file), they are going to strip out the protection. So let’s write off DRM.

    That’s not to say we should write off all forms of protection. Since we can’t stop the crackers, let’s concentrate on an area we can do something about, casual piracy. Consider a regular end user, who might view the source of a website, or checks their FireBug Net tab, and grab the font file to either install or use on their own system or website illegally. This is where SVG and EOT can play a role. EOT addresses both of these scenarios out of the box – it can be tied to a particular domain, so it cannot be easily installed on another website or blog, and it cannot be easily installed on an end user’s system folder, since it’s not a regular system font. By default, SVG addresses only one of these two problems – they can’t be installed on the user’s system, but they can be easily copied to another site. However, the EOT domain protection can be mimicked through the use of other web technologies. For example, you could serialize the SVG into a dataURL, and then further serialize that into some javascript (and even obfuscate and encrypt it if you wanted to), where you can do all the domain checks you want. This kind of protection is the ideal solution. It provides the maximum protection that DRM has ever been able to practically offer other – it makes it difficult for honest users to pirate fonts.

    It is true that with enough googling, downloads and virus scans, the tools are available to extract something like an installable font from PDFs, SWFs, and even SVG files. For an end user to do that, they need a specific intent to steal the material, as well as a the technical capability to actually pull it off. Here we are back into pirate land, and those guys are more likely to hop on usenet, or bittorrent sites anyway – or their local file server at work, rather than attempt to extract some half version of a font from a PDF, EOT, SWF or SVG font (which tend to be subsetted). Dealing with them is a job for lawyers and the law, and it not a technical challenge. Fighting them on the wrong front will cost more than it nets, in terms of lost sales from not participating (and not making sales), or from the support headaches of dealing with ill-conceived DRM technology.

    Having a font format that keeps the honest honest, is not too much for type designers to ask for. They spend a lot of time creating type faces, and frankly, they deserve some kind of protection from casual piracy – protection that is at least on par with the kinds of protection other forms of media are already receiving on the internet – and that even fonts are receiving in other formats, such as PDF and Flash SWF files.

    Web browser makers, should implement EOT font support, the format supported by the 10,000 pound gorilla – Microsoft‘s Internet Explorer – which is huge, but they probably will not due mostly to a lack of interest from someone willing to do that work – and maybe other concerns. Since that is the case, SVG glyph fonts are great second choice. They provide all the protection that can be reasonably expected from an online media format, and starting over with a new font format is undesirable, if it means we have to wait for 10 more years to get any progress. The upshot is, it’s already in most of the current alternative browsers! Only Mozilla‘s Firefox has yet to implement SVG glyph support – they do seem ready to do it. The future of HTML font embedding is looking bright!

    Update: I saw this earlier, but didn’t have the link handy. In bugzilla bug #119490 comment #15, John Daggett mentions that they plan to add this feature for Gecko 1.9.2. This is great news! It does mean more waiting though, as Gecho 1.9.2 is slotted to run whatever version of Firefox comes after the soon to be released 3.5 (3.6 at the moment).

  • No Embedded Web Fonts?

    I occasionally come across an argument against the implementation of embedded web fonts in web browsers and I wanted to comment on it.

    The argument is that embedding fonts in web pages should not be allowed, because either people don’t have the rights to use fonts that way, or because it’s too easy for users to steal the fonts, or some combination of the two. It’s debilitating for those who hold that position, and they may be missing out on a lot of potential opportunity. Craig Kroeger sells a set of fonts specifically for use in Adobe Flash, and even licensed them for distribution with Adobe Flash CS3. And that’s just for Flash designers. Imagine a market the size of the whole internet.

    Without proper web font embedding technology, there are too many hurdles to uses custom type faces on your website. You can use Photoshop created text graphics, and there are some tools to help make using custom typography on the net easier, like sIFR (which relies on the Adobe Flash Player). While these are creative solutions, they are pretty restrictive – limiting the use of fonts to small blocks of text, like headers. They can also be time consuming to set up, and there is no way for web page designers to use these techniques for body copy. So other than some sparse use here and there, web designers don’t even consider using – or licensing – fonts for web sites, and instead stick with the same 10 fonts that most people have on their systems already.

    Just as in print, or with photos or body copy, or any other licensable content, it’s on the shoulders of designers to make sure they are abiding by their license agreements. License templates exist that give designers the right to embed fonts in PDFs and other forms of distributable electronic document, and it’s generally well understood that the rights to images found on a web site belong to the owners that web site. When there are violations, friendly notices, or nasty-grams from the layers, seem to do the trick to get things resolved. These same principles undoubtedly apply to embedded fonts, and are no more complicated. Those are the solutions to possible abuse.

    If we must though, I would suggest a move to a middle ground, and follow the example of the natural restrictions placed on photos. Since photos are reduced in quality and in size when converted to jpegs, re-use is impractical for high quality output. So browser producers could consider a special, difficult for end users to install font format for embedded web fonts, something based on SVG maybe. This would probably be a good idea for a number of reasons anyway, including smaller file sizes and better cross platform compatibility. Fonts could then be converted and subsetted for use in web pages, in the same way that they are converted and subsetted for use in other web distributable formats, like Adobe Flash, Director, PDF, and Silverlight.

    I hope Opera CTO HÃ¥kon Wium Lie will stand by his publicly stated desire to see embedded web fonts come to Opera, and that something like that might be the catalyst that gets the other browser makers moving on embedded fonts.

    I think the time has long passed for embedded web fonts.