The reason for doing it is to solve the case when a newer API is no longer backwards compatible with an older API.

To explain, just say that there is an old API v1.0. The maker of this API decides it is broken and works on a new API v1.1 that intentionally breaks compatibility with the old API v1.0. Now, any programs written against the old API cannot be recompiled as-is with the new API.

Then lets say there is a large app written against the old API and the developer doesn't have access to the source code. A solution would be to re-implement a "custom" old API v1.0 in terms of the new API v1.1 calls. So the "custom" v1.0 API is actually keeping the same interface/methods as the v1.0 API but inside its implementation it is actually making calls to the new API v1.1 methods.

So the large app can be then compiled and linked against the "custom" v1.0 API and the new v1.1 API without any major source code changes.

Is there a term for this practice?

There's a recent example of this happening in Jamie Zawinski's port of XScreenSaver to the iPhone - he re-implemented the OpenGL 1.3 API in terms of the OpenGL ES 1.1 API. In this case, OpenGL 1.3 represents the "old" API and OpenGL ES 1.1 represents the "new" API.

  • 2
    API 1.0 would effectively become an adapter of API 1.1? If so, there's your answer...
    – yannis
    Jun 20, 2012 at 2:41
  • 2
    You need a name for your patterns book. How about Back to the Future Adapter?
    – psr
    Jun 20, 2012 at 3:05

2 Answers 2


If I understand you right, you'd be implementing the adapter pattern to isolate the API calls from the rest of your application. So when the time came to switch from v1.0 to v1.1, you'd just modify your API wrapper implementation to make different calls and the rest of your application wouldn't know or care.

So your application structure would look something like this:

.----------.       .-------------.       .----------.
| Your App | ----> | API Wrapper | ----> | API v1.0 |
'----------'       '-------------'       '----------'
                              |          .----------.
                              `--------> | API v1.1 |
  • Posting my comment as an answer? Well done! ;P
    – yannis
    Jun 20, 2012 at 2:42
  • +1 To the comment and the answer. So this is where Anna gets all her extra rep from ;) Jun 20, 2012 at 2:44
  • @YannisRizos The timestamps are almost on my side. :P
    – Adam Lear
    Jun 20, 2012 at 2:45
  • 29 seconds too late is still too late!
    – yannis
    Jun 20, 2012 at 2:46
  • 1
    @YannisRizos c'mon other guys repost her comments as an answer, why can't Anna do the same? :)
    – gnat
    Jun 20, 2012 at 5:01

Thanks to Anna Lear and Yannis Rizos for their answer, i.e. that the API 1.0 has effectively become an adaptor for API 1.1.

I just wanted to put forward a more specific answer. In my case the API 1.0 has retained the same public interface, so the application doesn't need to change. The only thing that has changed is the internal implementation of the API 1.0 itself - it now has a dependency on the new API 1.1. So instead of "porting the application" to use API 1.1, we're "porting the API".

Porting an API

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.