Top 10 Reasons to use Platform Native APIs

What are native platform APIs? They are the APIs provided by the platform vendor that define the platform. On Android this is the Android SDK. On iOS it is the Cocoa Touch Frameworks. On Windows and Windows Phone it is WinRT and the .NET Framework. There are undocumented APIs, and even calls that circumvent the platform APIs, but they are not considered part of the platform API.

In addition to the native development tool provided by the platform vendor, there are 3rd party development tools providers (such as ourselves) with their own solutions. The 3rd party tools typically either focus on providing a better solution for the specific platform, or sacrifice native platform support with the objective of cross-platform simplicity. There is no reason to sacrifice platform support, as you will see in these top 10 reasons to program to platform native APIs.

Platform Native APIs are Great

Those who programmed MS-DOS applications or the early Windows API no doubt remember what a pain those APIs (or lack of) were to work with. Back then it was great to have a good abstraction to make the platform easier to work with. Today’s platform native APIs encompass all the productivity enhancements that are found in the the best abstractions. Typically, the productivity enhancements that come from additional abstractions are only in the form of familiarity and developer’s resistance to learning a new API and framework. You know things are getting carried away when there is a Java abstraction for developing Windows Phone 8 applications and a .NET abstraction for building Android applications.

The Law of Leaky Abstractions

“All non-trivial abstractions, to some degree, are leaky.” If your tool forces you to use some non-trivial abstraction on top of a platform’s API, at some point it will leak – there will be something that the abstraction cannot do, or somewhere the abstraction behaves differently from platform to platform. If you are serious about developing for any platform, you need to understand the platform’s native API. The more non-trivial the abstraction, the less of the platform it can abstract successfully and the more likely you will need to move to the platform native API. If you are going to need to learn the platform API anyway, you might as well start there. No need to learn both the abstraction and the platform API – that is twice as much work.

Native Documentation

Documentation is a lot of work. Good documentation is even more work. On each platform, the platform vendor provides the documentation of the platform along with all the best practices and examples. For each additional level of abstraction that requires another level of documentation to consult. Chances are that the documentation will eventually refer you to the platform API documentation. Wouldn’t it be nice to just start at the ultimate authority and not have to wade through incomplete and outdated layers of documentation?

No Bloatware

If your abstraction adds additional graphic libraries or run-times, your application suffers with bloat. These abstractions replace the functionality already present in the platfrom and make your app bigger, slower to start-up and less responsive at runtime. Some of these add-ons are worthwhile, but if you need to double (or more) the size of your app just to write “hello world”, then you are probably using the wrong solution.

Rapid Release Cycle

When a platform vendor releases a new API you want to be able to take advantage of those features right away. It may surface new hardware features, or just introduce better ways of doing things. If you are forced to use an abstraction, you need to wait for the 3rd party to update their abstraction. This may be fairly quick, or you may have to wait for their release cycle, which, depending on where they are in development, could mean the release after the next. No matter how fast a vendor has been in the past at updating their abstraction library, a point will come where they are not updated when you need them.

Support for Platform Deviations

If a hardware vendor comes out with their own SDK extensions or variations on a platform, they will provide their support at the level of the platform API. If you are stuck behind an abstraction, you will not have access. The openness of Android is a great example with extensions like Google TV, Epsion Moverio, Ouya, and Google Glass. If you are interested in cutting edge platforms like these, you need a development tool that doesn’t lock you behind an abstraction.

Native User Experience

Each platform has a typical user experience. This comes from the native platform user interface widgets and the way they behave. It also comes from design guidelines provided in the platform documentation. If you are using an abstraction for your user interface, even one that tries to look and act like the native one, it will get in the way of this native user experience. When it comes to user experience, close isn’t close enough. Using the native platform user interface controls is the only way to give your users the experience they expect.

Less Points of Failure

Everything always works great in the demonstrations, but the more layers of interoperability and wrappers required to make your application run, the more points of failure. When you develop for the platform API directly, you are not handicapping yourself with black boxes or other points of failure for your app. The first time you find yourself debugging into that abstraction layer, you will really wonder if it was worthwhile to shackle yourself with it.

Maximum Developer Flexibility

Platform APIs are huge. In the process of creating a wrapper, choices are made to simplify or eliminate options. These simplifications and eliminations result in less flexibility for the developer. Tying a project to a subset of the features of the platform reduces what you can do with your project. Don’t tie your hands!

3rd Party Support

The majority of 3rd party components and books are going to support the platform’s API. The further you are from that, the less support you are going to have. Want to use a cool 3rd party custom control? Hope they port it to your favorite framework. And what are the odds of a book about the specific features of the platform you want to explore covering it via your specific pair of shackles?

Summary

Cross-platform abstractions are only going to get in your way and tie your hands. Any benefit in getting you up to speed faster will be lost in the long term when you hit the rough edges of the abstraction. That is the reason Oxygene is designed to use the platform native APIs directly. There is no forced or complex abstraction to get in your way of using the platform and making the best app possible.