This Week's Sponsor:

Kolide

Ensure that if a device isn’t secure it can’t access your apps.  It’s Device Trust for Okta.


Posts tagged with "SDK"

Facebook SDK 3.5 for iOS

Some nice updates for developers who integrate Facebook functionality in their iOS apps. A new native Share Dialog, with support for photos like the iOS 6 Share Sheet, will be available in beta today:

The native Share Dialog is simple to integrate and significantly improves people’s sharing experiences from your native mobile app. It has built-in support for publishing Open Graph actions. In addition, people now have the option to share activity from apps through this dialog without needing to login to Facebook first. This makes it faster and easier for people to share.

The data and publishing permission dialogs look good as well. Facebook says they’re 20% faster, too.

Permalink

Philips Releases Hue API and iOS SDK

hue

hue

As reported by TechCrunch, Philips has released an API and iOS SDK for the hue, the company’s wireless lighting system that gives users control through an iOS app.

We’re now at a point where there are already about 10 applications that have been shared and built from the unofficial developer community for new applications around Hue,” explained George Yianni, Hue System Architect in an interview. “Now what we want to do as Philips is we actually want to help and grow and encourage this community, and give them tools and proper documentation. Also, we want to give them commitment that this is the API and we’re going to support it and it won’t change overnight.

Prior to the official release of an API and SDK, third-party developers had already reverse-engineered Philips’ apps to create their own solutions to control hue’s system (based on a “bridge” that communicates with the actual lightbulbs). An iOS app called Ambify lets users pair their music with hue lights; here at MacStories, I linked to a video back in November showing an unofficial hue Python library that could work with Pythonista to automate the process of switching lights on and off.

The API opens a lot of interesting possibilities for third-party software and hardware makers. The hue already shipped with its own options for remote control and “presets” (called “recipes”) for different lighting settings aimed at providing users with ways to easily replicate specific color combinations based on photos (available in the app’s photo library) or targeted towards lifestyle improvements (such as waking users up in the morning with a gradual light increase).

With an SDK and API, developers can now take advantage of these concepts: aside from the “simple” remote control features, imagine apps that could activate specific hue settings when you’re reading or watching a movie, parse voice-based commands with dictation, or integrate with an iOS device’s Reminders, Calendars, or Location Services. On the hardware side, it should be possible – at least in theory – to develop gadgets capable of combining personal data with hue to leverage Philips’ “smart” lighting system in completely new ways. An obvious implementation would be for health and fitness-monitoring accessories such as Nike’s FuelBand; as far as rumors go, an Apple iWatch could integrate with hue to exchange an user’s data and personal stats (Apple isn’t new to third-party collaborations of this kind).

Right now, Philips’ hue API is promising and shows great potential for more forward-thinking software and hardware implementations. You can read more on Philips’ website.


Google Maps SDK For iOS And URL Scheme

Google Maps SDK For iOS And URL Scheme

Alongside the launch of its official Maps app for iPhone, Google has also released a developer SDK to let third-party apps embed Google Maps directly. As detailed by Andrew Foster at the Google Geo Developers blog, the SDK – which requires signing up for API access – will allow developers to integrate Google Maps with their own apps, displaying embedded 2D or 3D Maps views with markers and info windows. The blog post also confirms that the SDK will work on the iPad; Google has confirmed to The New York Times that a native iPad version of Maps is indeed coming.

The SDK features vector-based maps that load quickly, allowing users to easily navigate 2D and 3D views, rotating and tilting the map with simple gestures inside your app. Developers can also change the Google maps view to include information such as traffic conditions, and control camera positions in 3D.

In the SDK documentation, Google says that the appearance of Maps embedded through the SDK is the same of the Google Maps apps, and that the SDK “exposes many of the same features”.

However, the SDK isn’t the only way for developers to integrate with Google Maps. Using a URL scheme, developers can point to the Google Maps app and launch it from their app into a specific view or map object. Documentation for the URL scheme is available here. Developers can link to Google Maps with specific views, modes (standard or Street View), set zoom levels, and pass directions with the URL scheme.

It’ll be interesting to see how and when Google Maps-compatible apps such as AroundMe or WhereTo will support the new Google Maps SDK. The addition of a URL scheme shouldn’t be underestimated either, as it’ll enable regular users to launch the app using tools like Launch Center Pro.

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.


Developers Explain Changes in Growl 1.3

Developers Explain Changes in Growl 1.3

Speaking of Growl themes, the developers of the popular notification system for OS X have seen a bit of confusion after the release of version 1.3 on the Mac App Store. They have published a post with a summary of changes, and here’s the most important point:

Growl is still open source and under the BSD license, but version 1.3 is sold at $1.99 on the Mac App Store. This paid model allows the developers to work on Growl full-time.

So why upgrade to Growl 1.3 when the old version might still work? First off, to get the new features. More importantly, for a reason I didn’t know about:

Growl 1.2 and older will not work with Sandboxed applications - Sandboxing is meant to protect users from bad things happening (which is a good thing!), but it has consequences for applications which are doing good things too (like Growl). Apple announced this summer that Sandboxing is a requirement for all applications in the Mac App Store. As our developers who went to WWDC this year quickly realized, the impending Sandboxing requirement would have broken Growl entirely for applications in the App Store, for everyone, without a large amount of changes. Growl 1.3 introduces support for Sandboxed applications.

We may debate on the pros and cons of sandboxing, but the point is that, eventually, the old Growl will stop working with sandboxed Mac App Store applications. If new features and compatibility aren’t compelling reasons to upgrade, then I guess the problem is with those users not willing to spend $1.99, not Growl. The Mac App Store charts, by the way, seem to indicate Growl 1.3 has been pretty successful so far.

I use Growl on a daily basis and I like the new version a lot. Another thing I didn’t know about: apps written with the Growl 1.3 SDK will be able to display notifications even if Growl 1.3 isn’t installed. The system is called “Mist”, and a comparison table is available for developers here.

Permalink

TestFlight’s New SDK Brings In-App Updates, Checkpoints, More

In the recent months, TestFlight has become many developers’ favorite way of distributing internal “beta” builds of their iOS applications to testers. Thanks to the over-the-air installation method introduced by Apple in iOS 4, services like TestFlight allow developers to stop worrying about manually sending .ipa files to testers by relying on a unified web interface that collects testers’ UDIDs (deprecated in iOS 5), alongside other device information and app installation data. TestFlight has been largely successful thanks to its ease of use, nicely designed web apps and user adoption – with the release of a new SDK for developers, as noted by TechCrunch, the company aims to take a step further in letting developers access even more data from their testers and beta apps.

The SDK, available here, brings sessions, crash reports and checkpoints to TestFlight-installed apps. This means developers will be able to discover how testers are using their applications, and how far they’re getting thanks to virtual “checkpoints” placed in the app (useful for, say, level-based games, easter eggs or new, unusual interfaces). With in-app updates, beta apps built through TestFlight’s SDK will directly notify users of available updates without the need of checking email for new TestFlight updates. Similarly, in-app questions will enable developers to run small survey directly into their beta apps.

  • Over-The-Air - Painless App Distribution. Send your beta apps over the air with ease. It’s simple, painless, and magical.
  • Team Management - Get everyone on board. Manage devices and create custom distribution lists to selectively send builds over the air.
  • Feedback - Get the memo. Gather more feedback with in app forms and emails, which is all organized in your dashboard.
  • Reports - The Black Box of beta testing. Solve the mystery of beta testing. No longer wonder which testers installed the app, started testing, or opened their email invite. Reports bring transparency to beta testing, all in real time.
  • Checkpoints - Flag down insight. Monitor tester engagement and trigger in-app questions by placing checkpoints throughout your app.
  • Crash Reports - Crash, but don’t burn. Real time reports with environment snapshots, full session activity, and your NSLogs.
  • Enterprise - Enterprise signed IPA’s. The added benefit of unlimited devices with all the TestFlight features, at no charge.
  • In-App Questions - What’s up? Get the answers you need, by asking questions the moment a checkpoint is reached.

The TestFlight SDK allows you to track how beta testers are testing your application. Out of the box we track simple usage information, such as which tester is using your application, their device model/OS, how long they used the application, logs of their test session, and automatic recording of any crashes they encounter.

To get the most out of the SDK we have provided the Checkpoint API.

The Checkpoint API is used to help you track exactly how your testers are using your application. Curious about which users passed level 5 in your game, or posted their high score to Twitter, or found that obscure feature? With a single line of code you can find gather all this information. Wondering how many times your app has crashed? Wondering who your power testers are? We’ve got you covered.

Information gathered by the TestFlight SDK is sent to the web dashboard in real time, or after an app has been put in the background/terminated. The SDK has been in testing with selected developers for some months now, and the new features seem very welcome among the community. Developers using TestFlight include Spotify, Adobe, Marco Arment of Instapaper, The Iconfactory and Halfbrick, not to mention thousands of smaller “indie” devs trying out the service for the first time.

The TestFlight SDK supports Apple’s Enterprise distribution as well, and is available as a free download here.


iOS 5 Code Reveals Two New iPad Models

TUAW reports USB configuration files found in the iOS 5 beta seeded to developers last night reveal two new, unreleased iPad model identifiers labelled “iPad3,1” and “iPad3,2”. Considering that existing iPad 2 models are indicated in iOS as iPad2,1 (WiFi-only model), iPad2,2 (GSM) and iPad2,3 (CDMA), the discovery seems to indicate that earlier rumors of next-generation iPad getting a universal GSM/CDMA chip were correct. If that’s the case, iPad3,1 could point to the new WiFi model, with the iPad3,2 device being the one with dual GSM/CDMA capabilities.

In the same report, TUAW notes iOS 5 contains mentions of iPhone4,1 and iPhone4,2 models, though these were already spotted by Engadget in the iOS 4.3 beta code. However, the article also notes there’s no mention of iPod touch 5th generation in the current iOS 5 beta, leading to speculation that a new iPhone could be announced this Fall, but not a new iPod touch. On the other hand, Apple could still insert model identifiers in future iOS 5 betas set to be seeded this summer.

Model identifiers are usually a good indication of new products to come in the next months, and they correctly pinpointed new hardware before. The iPad 3 was initially rumored to be scheduled for 2011, although Apple made it clear at the March 2 event that 2011 would be the “year of the iPad 2” and a recent report claimed certification for iPad 3 components is only starting now, for a 2012 release.


1 Megapixel Rear Camera On The iPad 2?

Several rumors are pointing to the next generation iPad as a slight redesign of the original iPad, with tapered edges, flat back, bigger speaker and front / rear facing cameras. According to 9to5mac, which has done further digging into the latest iOS 4.3 SDK, the iPad 2 will have a 1 MP rear camera capable of shooting photos and videos, and a VGA front-facing one for FaceTime and other camera functionalities.

We’ve done some digging in the latest SDK it looks like Apple’s much rumored second-generation iPad will not feature some fancy 5 megapixel camera, but will instead shoot your flicks and take your pics with something close to a 1 megapixel camera. That’s awfully close to the fourth-generation iPod touch’s 0.7 megapixel back camera so we speculate they could be the same thing. That means you’ll be able to take some unwieldy 720P video with your iPad (whether you’ll be able to view that 720P video natively is another question).

The aforementioned SDK files reference to this device carrying a 1 MP camera as K94 and K95; the site speculates these codenames might refer to the next generation iPad. The current one, for instance, has codename K48. Multiple codenames for the iPad 2 might suggest that different versions are in the works, like iPad WiFi, CDMA and GSM. Other references found in iOS 4.3 beta seem to suggest the same thing.

A 1-megapixel camera on the iPad 2 would be significantly lower than the one found on the iPhone 4; we also have some doubts on the actual photo quality that would result from such a camera lens, which will have to display pictures on a 10-inch screen. Previous rumors indicated Largan Precision as the supplier of camera lenses for the next iPad, and a report in November also confirmed Largan was set to ship “5-megapixel lens modules for tablet PCs”.


References of New iPhones and iPads Spotted in iOS 4.3

A new OS comes along, and with a bit of digging into its code it reveals the secret of the next devices to come out from Cupertino. Engadget took a look inside the latest iOS 4.3 SDK and discovered mentions of new iPhones and iPads:

  • iPhone3,3
  • iPhone4,1
  • iPhone4,2
  • iPad2,1
  • iPad2,2
  • iPad2,3

To recap, iPhone3,1 and iPhone3,2 are the current models on AT&T and Verizon, respectively. While iPhone4,1 and iPhone4,2 point to the next-generation device known as “iPhone 5”, the 3,3 code reference suggests a new iteration of the iPhone 4. Perhaps the white one?

Oh, and about the iPads? We’re pretty sure those 3 models are for the iPad 2 in its GSM, CDMA and Wi-Fi only versions.