This Week's Sponsor:

PowerPhotos

The Ultimate Toolbox for Photos on the Mac

Posts tagged with "developers"

Apple’s Phill Schiller On App Store Curation and Promotion For Developers→

Apple’s Phill Schiller On App Store Curation and Promotion For Developers

In an interview with The Wall Street Journal published yesterday, Apple’s Phill Schiller weighed in on App Store curation, promotion of third-party apps, and traditional retail selling space.

The opportunity is the best it has ever been for software developers,” Mr. Schiller said, adding that he thinks the app store is a far more democratic way to sell software than traditional retail stores with limited shelf space.

Mr. Schiller also pointed out that Apple promotes apps in multiple ways, such as popularity charts and featured app lists. “Every other day you hear about another app going off the charts,” he said. “You can still get discovered and get a hit overnight.

There’s no doubt Apple has done a “tremendous amount” (Schiller’s words) to help apps get discovered on the App Store. With the iPhone and the App Store, Apple created a new economy that, in the U.S. alone, has spurred the creation of over 200,000 jobs. But as I have outlined last month, the App Store of 2012 isn’t the same that launched in 2008 to 900 apps: there are over 650,000 apps on the App Store today, and while Apple has done a lot for developers, it could optimize the layout of the Store to do more and better. I wrote:

Custom sections provide a decent solution to browse titles Apple has previously “curated”; however, these sections aren’t usually updated as often as they are created — N.O.V.A. 3, a new shooter game by Gameloft, still isn’t listed under Benchmark Games: Stunning Graphics, whilst the majority of reviewers and publications have outlined the game’s remarkable graphic capabilities.

The IconFactory’s Craig Hockenberry also noted how Apple could bring its “personal touch” to the App Store to showcase great software with different methods than simple Top Charts, or “curated lists” that are often abandoned and never updated.

Instead of fighting for a short-term placement in the Top 100 lists, we’d fight for a long-term product review. Look at the amazing things developers do to earn an ADA and imagine if that happened once a week. Earning that “Apple approval” could ensure a product’s success for a long time. Which would be great for both customers and developers alike.

Hopefully Apple is thinking about this stuff. Earlier this year they acquired app recommendation service Chomp, and they revamped their “App of the Week” section with a new “Editor’s Choice” tag. The redesigned App Stores of iOS 6 come with Facebook integration and improved layout for descriptions and screenshots, something developers have been asking for. It’s too early to tell, but it seems like the iOS 6 App Store is on track to deliver great improvements for navigation and user interaction this Fall; to improve discoverability and promotion, however, Apple should also consider tweaking longstanding minor, yet important aspects such as filters, search, and Category sorting options.

Read the full interview with Schiller (who also confirms a new tracking tool for developers being discussed at WWDC sessions) here.

Permalink

The Siri API→

The Siri API

Samuel Iglesias has written an excellent post detailing the (possible) challenges developers will have to cope with if Apple decides to release a Siri API.

The second half of Siri integration, Semantics, is the tricky part: something that most iOS developers have never dealt with. Semantics will attempt to capture the various ways a user can ask for something, and, more importantly, the ways Siri, in turn, can ask for more information should that be required. This means that developers will need to imagine and provide “hints” about the numerous ways a user can ask for something. Sure, machine learning can cover some of that, but at this early stage Siri will need human supervision to work seamlessly.

This is exactly what I have been wondering since speculation on the Siri API started last year. How will an app be capable of telling Siri the kinds of input (read: natural language) it accepts? Will developers have to do it manually? Will Apple provide a series of automated tools to associate specific features (say, creating a task in OmniFocus) with common expressions and words? And how is Apple going to look into the natural language processing developers will implement in their apps?

Of course, the Siri API is still at the speculation stage, but it does make sense to greatly expand upon Siri’s capabilities as an assistant capable of working with any app. The TBA sessions at WWDC are intriguing, and Tim Cook said we’ll be pleased with the direction they’re taking with Siri. Right now, I’d say integrating with third-party software would be a fantastic direction.

Permalink

Mac App Store vs Buying Direct→

Mac App Store vs Buying Direct

Wolf Rentzsch has published a good piece outlining the pros and cons of buying software through Apple’s Mac App Store, or directly from a developer’s website.

Some developers are going out of their way to allow seamless cross-grading from Mac App Store versions of their apps to direct apps, which is commendable and helps alleviate somewhat the situation Apple has created. Sandboxing is just the latest App Store rule change, I’m sure there’s more to come. All things being equal, it’s safer to buy directly instead of being cut off from your own software based on an arbitrary Apple policy change.

Sandboxing may be the latest requirement to get apps on the Mac App Store, but the trade-off involved with selling software through Apple’s channel has stayed the same since 2011: exposure vs. risk of change due to Apple’s policy. Because the environment is controlled and actively promoted by Apple, a developer gets all the perks of a store pre-installed on every Mac: millions of potential customers whose buying decision is just a click away, and nicely designed sections to showcase new apps (though Apple has to do more). On the other hand, because Apple gets to decide which apps and which functionalities are safe for the App Store, changes happen, like Sandboxing.

For the user, the convenience of the Mac App Store is obvious. Purchases are tied to an Apple ID, updates are easy, and the ecosystem is integrated with an existing structure (iTunes). Unlike John Gruber, I don’t think Sandboxing will be compelling for typical users, as I don’t see Apple showcasing Sandboxing-enabled apps the way they did for iCloud-enabled apps or apps updated with Lion features. It’s too technical, but Apple may figure out a way to market it (perhaps again the “Apps Enhanced for OS X Lion” section with new additions).

For developers, the Mac App Store means exposure to millions of eyeballs but also to Apple’s ever-changing strategies and technologies. The problem with Sandboxing, I believe, is that it introduced a change that is forcing developers of existing apps to reconsider functionalities that are not compatible with the Mac App Store anymore. If this will lead to serious fragmentation of Mac software with a proliferation of deeply different Mac App Store and “website versions” of the same apps, we’ll see.

Also worth reading: Lex Friedman’s story at Macworld on the first day of Sandboxing in the Mac App Store.

Permalink

Apple Confirms Sandboxing Deadline For Mac App Store Apps on June 1

In an email sent to registered Mac developers earlier today, Apple has confirmed it will begin enforcing a deadline on Sandboxing for Mac App Store apps on June 1, 2012.

As a reminder, the deadline for sandboxing your apps on the Mac App Store is June 1. We’ve made the process easier with new sandboxing entitlements and APIs now available in OS X 10.7.3 or later and Xcode 4.3.2.

If you have an existing app on the Mac App Store that is not sandboxed, you may still submit bug fix updates after June 1. If you have technical issues that prevent you from sandboxing your app by June 1, let us know.

Previously pushed back from November 2011 to March 2012, and then again from March to June 1, 2012, sandboxing is a new technology aimed at limiting an application’s access to certain areas of OS X through a system based on entitlements. As we wrote in February:

Sandboxing is a new technology in OS X Lion that limits the functionalities of Mac App Store applications to a list of “entitlements” that cover various areas of the operating system an app can access, such as networking, printing, or a user’s files. A sandboxed application would be unable to harm the system outside of its operational scope (managed by the entitlements), and this has caused some concerns as apps would lose access to the Mac’s entire filesystem, which is required by some functionalities of certain applications that aren’t necessary malicious or “compromised”. Similarly, inter-app communication would be a technical issue with sandboxing, as apps like TextExpander, Keyboard Maestro and CoverSutra — utilities that perform actions in the background without asking for user’s interaction in some cases (user-initiated actions can override the sandbox) — couldn’t get past the sandboxing requirement for the Mac App Store.

With today’s reminder, Apple has confirmed that new apps submitted to the Mac App Store after June 1 must adopt sandboxing, whilst existing apps that are not sandboxed will still be available to receive bug fix updates. Earlier this week, a report suggested that, in relation to the upcoming sandboxing deadline, Apple was also looking into “banning” new apps with “hotkey” functionality, though it appears that such policy won’t take effect, according to several sources. Recently, several OS X developers expressed their wish for Apple to further delay the sandboxing deadline to the end of June in order to better explain the ramifications of the technology at the upcoming WWDC. Unfortunately for those developers who were hoping for a revised deadline for apps that have proven to be incompatible with sandboxing, WWDC kicks off on June 11 – 10 days after the sandboxing deadline.

A number of Mac applications using Sandboxing are already available on the Mac App Store. Most notably, 1Password by AgileBits implemented the technology back in September 2011, and others like Edovia’s Screens for Mac and, recently, Pixelmator were updated with support for sandboxing as well.

Four Years of App Store: Developers Weigh In On Search, Discovery, and Curation

“The App Store is a grand slam, with a staggering 10 million applications downloaded in just three days”. That’s how Apple co-founder and late CEO Steve Jobs saluted the launch of the company’s new storefront for iOS (née iPhone OS) applications on July 14, 2008. Almost four years and over 25 billion downloads later, the App Store has evolved into a brand that spans two platforms (iOS and OS X), three different iOS devices (iPhone, iPod touch, iPad), a variety of Macs, and that hosts over 600,000 apps from more than 200,000 registered developers. Albeit minimal in terms of revenue for a company that makes billions off iPhones and iPads, the App Store created a new economy that nurtures an ecosystem ultimately aimed at selling more devices, as well as showing consumers that, nowadays, software is revolutionizing the way they approach work, entertainment, and other personal tasks. In spite of its tremendous growth, however, little has been done to improve a basic premise of the App Store: finding new apps.

“Discovery and search has been a huge concern of mine for a long time”, said Craig Hockenberry, Principal at design and development studio The Iconfactory. Hockenberry and his team were among the first developers to support the App Store in 2008 with Twitterrific, a Twitter client for iPhone that has expanded to the iPad and Mac, with different versions available on the App Store and Mac App Store. In 2009, a year after the App Store launched, Hockenberry offered a series of suggestions to Apple in order to improve certain aspects of the App Store – namely, following early discussions with developers that decided to sell software on the “iTunes App Store”, he noted how there was “still much room for improvement” to turn the App Store into a viable and reliable business platform for developers who weren’t simply interested in experimenting with it.

Hockenberry’s “Year two” post still rings true today, in spite of the functionalities that Apple fixed, improved, or brought to the App Store in the past four years. For instance, Apple created a “New and Noteworthy” section on the homepage of the App Store that is refreshed on a weekly basis to showcase apps Apple deems worthy of attention; promotional codes, which Hockenberry listed as one of the tools that had helped them sell more products, were made available internationally in late 2010; either on print, its website, or YouTube, Apple has kept pushing ad campaigns to educate iOS and Mac users on the importance and convenience of the App Store.

The very motto that started the app revolution, however, didn’t meet an equal amount of attention by Apple in terms of improvements for the infrastructure behind it. As Hockenberry wrote in 2009, “it’s incredibly hard to find the “that” in “there’s an app for that.” Between keyword spamming and the sheer volume of choices in each category, customers can’t find what they want”.

Read more

Apple To Reject Mac Apps With “Hotkey Functionality” Starting June 1? [Updated]

According to TUAW, Apple will start rejecting Mac apps with “hotkey functionality” starting June 1, when the deadline for Sandboxing will become active for Mac App Store developers.

Apparently, Apple will allow hotkey apps that are already in the Mac App Store before June to offer only bug fixes. New apps and any apps that add features (i.e. non-bugfix releases) will not be allowed to support hotkeys.

TUAW has been told that Apple will be rejecting all apps with hotkey functionality starting June 1, regardless of whether the new features are hotkey related or not. Basically, if you’re developing one of those apps, an app that assumes you can still add hotkeys, don’t bother submitting it to the Mac App Store.

While TUAW doesn’t specifically mention any Mac app that would be subject to this new restriction, it is safe to assume that by “hotkey functionality” they mean desktop applications that allow users to set up keyboard shortcuts to activate other apps or system locations (such as Apptivate), or an app’s specific functionality (such as Alfred’s hotkey to show a search box, or OmniFocus’ hotkey-based Quick Entry panel).

I spoke to various developers of Mac apps with system-wide hotkey functionality, and they were unaware of the changes that Apple may begin to enforce on June 1. Currently, there is no mention of such specific change in the Mac App Store Review Guidelines (or Sandboxing FAQs), and the APIs used by the developers I contacted aren’t deprecated in the latest Mountain Lion Developer Preview, updated yesterday. Some developers told me Apple may have rejected some apps that registered hotkeys without a user’s explicit consent, but according to TUAW the issue is different, and related to the kind of control and experience that Apple wants on the Mac App Store, rather than technical limitations or APIs.

Initially pushed back from November 2011 to March 2012, and then again to June 1, 2012, Sandboxing for Mac apps has found a considerable amount of skepticism in the Apple developer community, as it would pose a threat to existing Mac apps that would have to rework their functionalities around the limitations of sandboxing.

As I wrote in February:

Sandboxing is a new technology in OS X Lion that limits the functionalities of Mac App Store applications to a list of “entitlements” that cover various areas of the operating system an app can access, such as networking, printing, or a user’s files. A sandboxed application would be unable to harm the system outside of its operational scope (managed by the entitlements), and this has caused some concerns as apps would lose access to the Mac’s entire filesystem, which is required by some functionalities of certain applications that aren’t necessary malicious or “compromised”. Similarly, inter-app communication would be a technical issue with sandboxing, as apps like TextExpander, Keyboard Maestro and CoverSutra — utilities that perform actions in the background without asking for user’s interaction in some cases (user-initiated actions can override the sandbox) — couldn’t get past the sandboxing requirement for the Mac App Store.

In the past months, a number of notable Mac developers have voiced their concerns in regards to sandboxing: Daniel Jalkut of Red Sweater Software wrote that “to increase adoption, Apple should expand the current list of entitlements until it covers every reasonable behavior that users expect from Mac apps”; following his decision to stop selling Clipstart on the Mac App Store, Riverfold’s Manton Reece noted how, rather than playing “catch-up” with Apple to work around the list of entitlements for sandboxed apps, he’d prefer to keep selling his apps on his own website – something that the upcoming Mountain Lion will keep supporting thanks to GateKeeper.

Over at TUAW, Erica Sadun says we should say goodbye to “hotkeys, macro programs, end-user customization”. While I can’t confirm the kind of apps and “hotkey functionalities” that Apple has apparently already rejected or will start rejecting in two weeks (I’ve only seen some discussions about clipboard managers and keyboard shortcuts on the Mac Dev Forums), it would surely be unfortunate to lose software like Alfred, Apptivate, or Keyboard Maestro (just to name a few) to an updated Mac App Store policy. Erica Sadun refers to these hotkey-enabled apps as “all those great little hotkey shortcuts that used to let us bring an app to the forefront and do something”.

That sandboxing would be a technical issue for apps based on AppleScript technologies is nothing new; however, Apple also specifically asked developers to get in touch with the company if technical issues were preventing them from sandboxing an app, suggesting that the company was actively working on getting developers of existing great Mac software on board with sandboxing, without limitations. This week, the Pixelmator team updated their application with support for sandboxing; other developers of “power-user” applications like Keyboard Maestro, however, still haven’t found a proper way to work around sandboxing entitlements, going as far as writing “Keyboard Maestro requires access to other applications to perform your macros and so is not, and cannot, be sandboxed” on the app’s Mac App Store page.

According to Apple’s notice from February, developers of existing apps on the Mac App Store that are not sandboxed may still submit bug fix updates without sandboxing their apps. In theory, this should mean that apps like Alfred or Shortcuts (with hotkey functionality) or Keyboard Maestro (for general incompatibility) should stay on the Mac App Store as long as their developers don’t include new features, but only bug fixes for existing customers. But what’s going to happen when developers of hotkey-enabled apps or already-approved macro programs like KM will decide to update their apps with new features?

Just like in February, the future of sandboxing and Mac App Store apps is uncertain, but it’s looking worse if Apple really has decided to ban hotkey functionality – a common trait of keyboard-based software, such as Mac apps – from the Mac App Store. With the WWDC ‘12 scheduled to kick off 10 days after the proposed sandboxing deadline, here’s to hoping Apple will, once again, be more flexible, and offer third-party developers new ways to work around sandboxing – the Mac App Store deserves all kinds of OS X software, from simple single-purpose utilities, to more complex, power user-oriented applications.

Update: Throughout the day, several developers I spoke to confirmed my earlier reports that the APIs to implement global hotkeys and keyboard shortcuts haven’t been deprecated (not even in Mountain Lion), and aren’t going away any time soon. Two developers I spoke to, in particular, confirmed that recent updates to their Mac apps with “hotkey functionality” were approved without issues by Apple.

Furthermore, developers confirmed they couldn’t find any new mention of hotkey-related entitlements in today’s updated documentation for Gatekeeper and Sandboxing. So while more “complex” utilities like Keyboard Maestro and TextExpander may still have to find a way to work around Sandboxing, other apps that incorporate hotkey functionality – like OmniFocus, Alfred, or just about any app that offers a systemwide shortcut – should still be fine for the Mac App Store.

Lex Friedman at Macworld confirmed with his own sources that a ban for general “hotkey functionality” isn’t coming to the Mac App Store, writing that “so long as developers use Apple’s officially supported APIs to register systemwide global hotkeys, their apps will remain eligible for inclusion in the Mac App Store”.

iCloud and iOS Games→

iCloud and iOS Games

TouchArcade’s Brad Nicholson asked some indie iOS game developers about iCloud and support for syncing save states across devices:

It’s also obvious to us that iCloud and the implementation of it needs to be easier, and the service itself needs to be more reliable. Almost every studio we talked to had some trepidations or a horror story to share. Browse our message board, and you’ll find even more from users receiving the bad end of an iCloud problem.

That’s not to say iCloud isn’t awesome. It is. Games that use it, like Infinity Blade 2, are better for the implementation. iCloud could also be used for stuff beyond saves, so there’s promise of what’s to come. We simply want to see more of it.

In the case of smaller, independent developers of games for the iPhone and iPad, money is the main reason why iCloud often gets cut off from the list of features to implement at the last minute. For as much as we like to think of indie games as modern versions of DOS games programmed in a garage with virtually zero costs and lots of caffeine (and weird haircuts), the reality is that creating the latest $0.99 hit for iPhone is based off real business rules with real associated costs. As TouchArcade quoted a developer saying, “keep making games” is just as important as “making games”. The business side of things needs to be taken care of; when time is running out, iCloud typically gets sacrificed for the greater good – shipping the game.

I believe, however, that there is a deeper reason as to why developers are choosing to think about iCloud at the last minute. Why aren’t developers considering native iCloud integration from the get-go? And why is that only bigger, triple-A titles have been able to successfully use and ship with iCloud integration so far?

When I talked to developers about the first six months of iCloud, the reaction was the same: iCloud is great when it works, but there’s a need for better documentation and debugging tools. iCloud requires a lot of technical work to be implemented and customer support once it’s made available; not all developers are willing to go through this effort right now, and, unsurprisingly, only bigger development studios with consequently bigger budgets and support staff are pursuing iCloud sync for games.

With the WWDC approaching, here’s to hoping Apple will incentivize developers to consider iCloud integration as the foundation for apps and games. Third-party software is better with iCloud, iOS is better because of iCloud, but the platform for the next decade needs to find its early adopters in the people that will ultimately improve the platform going forward: iOS developers.

Permalink

11.13 and The Dropbox SDK

Apparently, Apple has been rejecting some iOS apps with Dropbox integration lately (at least during the past week) for linking to the Dropbox website through the login/sign up process. The Next Web has a rundown of the “issue”.

Apps that integrate with Dropbox, in fact, can either authenticate through the installed Dropbox app, or, if not installed, open a web view to let users log in with the browser. The alleged problem with Apple is that the Dropbox mobile login page contains a link to go back to Dropbox’s main website/account creation page, and possibly purchase a subscription bypassing Apple’s App Store (and thus 70/30 revenue split).

Of course, this isn’t new. In its App Store Review Guidelines, Apple has been enforcing for years a policy that doesn’t allow developers to visibly link to external websites that contain links to subscriptions sold outside of iTunes

Apps that link to external mechanisms for purchases or subscriptions to be used in the app, such as a “buy” button that goes to a web site to purchase a digital book, will be rejected.

In the past, a number of developers and services that included buttons/links to external websites containing subscription options were forced to update their apps to remove such functionalities. The most notable example to date has probably been the official Kindle app, which removed a button that linked to Amazon’s Kindle Store (where books can be purchased with an Amazon login, and saved into Amazon’s cloud locker). The list goes on, and the core issue at hand seems to be just how visibly developers are linking to external websites featuring “external mechanisms for purchases or subscriptions”. There doesn’t seem to be a “visible” link to purchase additional Drive storage on Google.com, but you get the possible irony of this scenario. In the past few days, if these forum posters are to be believed, Apple decided to reject some apps that offered “an external link to Safari to create a Dropbox account”.

Before we march to Infinite Loop with our community pitchforks and torches, there are some necessary notes to be made about these rejections. First, the latest public version of the Dropbox iOS SDK is 1.2.1, available here, and I know at least two apps – Ultimate Password Manager and Drafts – that use it, and were approved today. Dropbox integration isn’t a central feature in these two apps, but they do have the Dropbox SDK built-in. On the forums – thus, not on the public developer page – the Dropbox team has already released a “beta” version of the 1.2.2 SDK, which removes the option to create an account on Dropbox.com. The beta SDK was seeded a few hours ago, and there’s the possibility Apple will reverse its decision on those rejections once they see the removal of the incriminated links. Right now, we don’t know.

Perhaps more interestingly, Dustin Curtis notes how some developers had also trouble linking to Rdio content inside their apps. It’s interesting, because Rdio came up with its own way to comply with Apple’s terms without losing money: they are offering subscriptions at a higher price through in-app purchase. But then again, the issue isn’t that Rdio does offer IAPs in its iOS app (the restriction on different prices was relaxed last year): it’s that the Rdio website still displays links to subscriptions users may potentially purchase through Safari (or any iOS web view).

As iOS apps become increasingly connected with third-party services and APIs, it’s going to be difficult for developers to keep track of websites and login pages that may or may not contain purchase mechanisms Apple doesn’t like. Sometimes, these mechanisms go unnoticed for months; other times, Apple decides to take action, such as in the (reportedly few) cases of Dropbox rejections this week.

Does this signal a change in Apple’s stance on Dropbox-enabled apps? We don’t know, though developers are naturally asking for clarifications and expressing their doubts. It may well be that Apple decided to simply start enforcing its old existing rule, and that they will be perfectly fine with the new SDK for newly-submitted apps. More importantly, while these few rejections are being talked about now, it’s important to note how, this week, other apps with the old Dropbox SDK have been approved.

Apple’s 11.13 rule isn’t new, and before we dabble in speculation about Apple wanting to “kill Dropbox”, I suggest we wait.

Apple Announces WWDC 2012: Kicks Off June 11

UPDATE: Apple has confirmed that tickets for WWDC 2012 are already sold out.

Apple has announced the official dates for WWDC 2012. The developer event kicks off in San Francisco on June 11 and runs through June 15. Tickets are on sale for $1599, and are limited to one ticket per person or five tickets per organization. This year, app developers under 18 years old (13 - 17) can have their legal guardian purchase a WWDC ticket and approve their attendance at the conference — budding developers do not have to miss out on this year’s events.  Despite being an ever popular event that sells out quickly, WWDC 2012 still takes place at Moscone West.

We have a great WWDC planned this year and can’t wait to share the latest news about iOS and OS X Mountain Lion with developers,” said Philip Schiller, Apple’s senior vice president of Worldwide Marketing. “The iOS platform has created an entirely new industry with fantastic opportunities for developers across the country and around the world.

Registration for the event will take place on June 10th starting at 9:00am. If the event cannot be attended, videos from this year’s sessions will be made available for download. It’s best to go in person so experts can answer your development related questions. This year’s topics will include information about OS X Mountain Lion, which will be made available later this summer, alongside iOS app development sessions.

WWDC 2012 will cover six technical tracks with over 100 sessions and labs. Tracks include:

  • Essentials
  • App Services
  • Developer Tools
  • Graphics, Media, and Games
  • Safari and Web
  • Core OS

Alongside ticket sales, Apple has opened nominations for the 2012 Apple Design Awards. Nominated apps will be considered for an ADA and must be made available on the App Store or Mac App Store by May 1st. Students can also look forward to a great time at WWDC, and earn the chance to attend the conference free of charge on a scholarship.

Activities at Apple’s WWDC 2012 include:
more than 100 technical sessions presented by Apple engineers on a wide range of technology-specific topics for developing, deploying and integrating the latest iOS and OS X technologies;100 hands-on labs staffed by more than 1,000 Apple engineers providing developers with code-level assistance, insight into optimal development techniques and guidance on how they can make the most of iOS and OS X technologies in their apps;the opportunity to connect with thousands of fellow iOS and OS X developers from around the world—last year more than 60 countries were represented;engaging and inspirational lunchtime sessions with leading minds and influencers from the worlds of technology, science and entertainment; andApple Design Awards which recognize iPhone®, iPad® and Mac® apps that demonstrate technical excellence, innovation and outstanding design.

PR after the break!

Read more