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 "iOS 6"

iOS 6 Mockups→

iOS 6 Mockups

The Verge Forums member “gizmosachin” created some nice mockups of iOS 6 and the next-generation iPhone based on recent rumors.

Well this week we saw the “composite” image of the new iOS 6 Maps app, the blurrycam photos of the new iPhone, and with the WWDC 2012 app it seems that iOS 6 will make most UI elements silver like their counterparts on the iPad. Thought I’d make some mockups of the new iPhone running Safari and the supposed new Maps app just for fun. I couldn’t find any high res C3 Tech images so I just used the OpenStreetMap maps that Apple currently uses in iPhoto.

According to speculation surrounding the next major version of iOS, Apple will switch to a “silver” theme – roughly the same that has been used on the iPad since iPhone OS 3.2. Marco Arment believes the iPhone UIKit widget styling (the stock blue element) is out of style. Cult of Mac thinks that the recently released WWDC app and iPhoto for iOS set the stage for silver coming to the iPhone soon.

In theory, apps that use stock UI items provided by Apple would work “out of the box” with an updated color scheme. However, developers who relied on custom icons, colors, and other patterns would still need to optimize their apps for the new UIKit – and that’s exactly why Apple “previews” new version of iOS at WWDC before their Fall release.

Composite mockups of iOS 6 Maps based on “leaked” screenshots of the software first surfaced last week. Check out more mockups at The Verge.

Permalink

MG Siegler: Facebook Integration Coming To iOS 6→

MG Siegler: Facebook Integration Coming To iOS 6

According to MG Siegler at TechCrunch, Apple’s upcoming new version of iOS – set to be unveiled at WWDC – will feature Facebook integration, similarly to how Twitter was integrated into iOS 5 last year.

It’s important to note that Apple being Apple, something could change in the next week and a half (see again: Facebook/Ping). But as of right now, Facebook is a go in iOS “Sundance”. One thing still being hammered out according to our sources is how sharing will work. Sharing is the other big part of the iOS/Twitter integration, and will be important for iOS/Facebook integration as well. But Facebook is significantly more complicated than Twitter in that there are all kinds of permissions for what you can post where and who can see what. And Open Graph adds another layer of complexity to all of this.

It is unclear for now how Facebook integration could work at a system level on iOS, presumably allowing users to share status updates, photos, and videos. Taking Twitter integration as a reference, it is worth noting how Apple doesn’t let users casually tweet at any time from iOS, having enabled the “tweet sheet” only in specific applications such as Safari and Photos. Facebook is more complex than Twitter in terms of privacy controls and functionalities, and we can only assume the system integration Apple has worked on will still strive for simplicity and intuitiveness when communicating with the service.

There are a series of factors as to why Apple could add Facebook integration to iOS. Firstly, such integration was spotted years ago into an unreleased build of iOS 4. Then, recent remarks by Apple CEO Tim Cook confirmed the two companies have mutual respect for each other, and that they are working closer together to provide the “best experience” with Facebook to iOS users. Tim Cook himself said to “stay tuned” about it. Last, Facebook’s own apps for iOS (including the recently released Facebook Camera) and the plethora of third-party Facebook-connected apps could incredibly benefit from direct integration on iOS.

Apple’s WWDC kicks off on June 11 in San Francisco.

Permalink

iOS 6 and Files.app

Rene Ritchie thinks Apple should provide direct document access with iOS 6 through a dedicated Files.app:

A unified document repository, modeled after the existing unified image repository, rounded out with more consistent attachment options, could be the best of all worlds. Users wouldn’t have to remember which folder a document was in, nor which app. They wouldn’t have to jump around to edit or share. Users could simply open any app capable of editing or sharing a certain type of app and go to work.

I agree with the notion that the current Open In, app-based document transfer model of iOS is broken. The simplicity brought by iOS freed average users from the complexities of the filesystem; people who like to get their daily work done with iOS devices, however, miss a unified document filing system. Paradoxically, the “simple” iOS, with its “Open In” menu and multiple copies of the same document, requires people to manually manage more.

In February, I envisioned something similar to Rene’s proposed Files.app solution:

So, I had an idea. I think the same iTunes File Sharing feature would work a lot better as a dedicated, native iCloud app for iOS devices (and maybe the Mac too). After all, if Apple is providing an iTunes-based file management utility for Mac users, why couldn’t they build an app that enabled any third-party iOS app to save and import files from iCloud? This app would be built into the system and allow users to simply collect documents, like iTunes File Sharing. Developers could easily add options to their apps to import files from “iCloud File Sharing” and export files to it. Users would have the same feature set of the existing iTunes File Sharing, only with an interface they are already familiar with, because iCloud File Sharing would resemble the existing file management workflow of iWork for iOS or iCloud.com. The only difference is that it would be integrated on a system level, work with any iOS app, and basically be an extension of the “Open In” menu that already allows apps to communicate with each other through supported file types.

After having tried the latest developer releases of Mountain Lion and putting some more thought on the matter, though, I am not so sure about the centralized repository system anymore. Namely, I am not convinced it should be a separate app.

Rene rightfully compares the possible Files.app to the existing Photos.app for iOS. Files could present document folders the same way Photos displays image albums, and it could have the same systemwide hooks to let other apps access documents from the unified repository. However, there is a difference worth noting: Photos.app gets its contents from a primary, hardware-based component of iOS – the camera. A user takes a picture, it goes into Photos. Same for videos and screenshots – the interaction is simple.

What is a file, though? Is it a text document? RTF or .txt? If so, does Files.app come with preview capabilities for those file types? Or is it about PDFs, .zip archives, folders, and .cbr files? And how do you get documents into Files.app?

Even by only slightly mimicking the Finder, Files.app could reset the past five years of “simple” iOS interactions in one big fell swoop. Photos itself, which is extremely straightforward, is criticized for its file management features. Now imagine that applied to the general concept of “files” with folders, views, sorting options, settings, and previews.

Today, I think what I wrote back in September could make for a better solution: inter-app communication.

Why can’t Apple build an invisible layer that lets Elements edit a text document from Evernote and Pages access the same file?

It turns out, a possible implementation of such layer already exists, but iOS won’t let apps communicate with it. Enter iCloud Documents & Data:

The same interface is available on OS X:

And in Mountain Lion, the standard file-saving dialog has been enhanced with the addition of an iCloud option (image via Macworld):

The design is slightly different since the first Mountain Lion Developer Preview that Macworld reviewed, but the concept has stayed the same throughout betas: Apple apps like TextEdit and Preview can “hold” documents into a special iCloud folder (located under Library/Mobile Documents/appname/Documents on OS X); these documents also show up on iOS under Documents & Data; currently, they are not available on iCloud.com, nor is Mountain Lion’s file-saving UI allowing, say, Preview to easily grab a file from TextEdit’s own iCloud “folder”. However, on Mountain Lion, Apple says that you can get your “existing documents” into iCloud by dragging them from the Finder or “other apps”.

If the system Apple has been putting in place is of any indication, I think enhancing the app-based model with better communication would actually outmatch the possible benefits of a separate Files.app. Documents & Data could become a document picker developers can enable in their apps with an API; because apps register file types they support, Apple wouldn’t have to worry about creating a Files.app capable of previewing every single format out there. GoodReader could open a PDF from Pages’ iCloud, and Pages could later access that same PDF with the changes made by GoodReader.

I am arguing that apps should become their own centralized locations that other apps can access and interact with – without creating duplicate files. Apple can’t provide the basic preview/edit functionalities of Photos for every possible format supported by Files.app, but 600,000 App Store apps might have the solution for that. Rather than creating an additional layer of management – disconnected from apps – iOS 6 could turn the interface already in place into a document picker that gives files their proper meaning: the app they belong to. Only with the addition of inter-app access and “universal save” to avoid duplicates.

Making changes to a single file with a variety of apps is something we do every day on our Macs. On OS X, there’s the Finder that acts as a glue between apps and files. By design, the technical constraints of iOS have turned non-destructive editing into a clunky and confusing experience, as we’ve seen with iPhoto. I am arguing that instead of building a “Files.app” or “Finder for iOS”, Apple could leverage the existing iCloud Documents & Data UI, and rework the iOS architecture to allow for changes to the same document from multiple apps.

The centralized Files.app idea is certainly appealing, but Apple has heavily invested in the app metaphor for the past years, and rather than replacing it with a new layer, I wouldn’t mind seeing it get smarter.

New iOS 6 Maps App To “Blow Your Head Off”→

New iOS 6 Maps App To “Blow Your Head Off”

John Paczkowski at All Things Digital confirms a rumor published this morning by Mark Gurman at 9to5mac: Apple’s forthcoming iOS 6, set to be announced at WWDC, will feature a new Maps application based off Apple’s new mapping backend.

We’ve independently confirmed that this is indeed the case. Sources describe the new Maps app as a forthcoming tent-pole feature of iOS that will, in the words of one, “blow your head off.” I’m not quite sure what that means, and the source in question declined to elaborate, but it’s likely a reference to the photorealistic 3-D mapping tech Apple acquired when it purchased C3 Technologies.

That Apple was going to replace Google Maps with a different technology – and quite possibly its own – is nothing new, at least from a rumor perspective. In the past years, a series of tidbits of information and facts seemed to suggest that Apple was on track to deliver a different Maps application for iOS in the future. Last summer, a series of legal disclaimers pointed at various mapping technologies being used by Apple in iOS, but the rumored new mapping tech that was allegedly meant for iOS 5 didn’t ship with the major update in October, as Apple and Google renewed a deal to use Google Maps in iOS.

In April 2011, Apple confirmed they were “collecting anonymous traffic data to build a crowd-sourced traffic database”, although without specifying whether such service could see a public implementation in a new Maps app for iOS. More than a year ago, we wrote how “in the past years, several job listings on Apple’s website hinted at open positions in the iOS team for map engineers and navigation experts, suggesting that Apple was working on its own proprietary solution to ditch Google Maps on the iPhone, iPod touch and iPad. The acquisitions of mapping companies Placebase and Poly9 in 2009 and 2010, respectively, gave some credence to the reports that pointed at Apple willing to become the next major player in the mobile mapping scene.”

Most recently, Apple officially acknowledged they are using OpenStreetMap data in iPhoto for iOS.

Permalink

iOS 6 Wishes

I read two great articles over the past few days detailing how Apple could improve iOS by taking a page from its competitors’ book (specifically, Android and Windows Phone 7) to enhance the way apps communicate with each other, and by looking at the way webOS handles multitasking and application windows on the TouchPad. They are good articles with some clever ideas, so make sure to check them out.

I have been writing a lot about ecosystems, file sharing and inter-app communication in the past months. After the public launch of iCloud last October, I’ve argued that Apple’s cloud solution is the platform for the next decade that might as well become the “operating system” itself, although it (and, by reflection, iOS) still lacks document-oriented functionalities to facilitate the process of creating and moving documents between apps. I have also made the case for a “universal save” option for iOS apps that might take advantage of iCloud, and, fortunately, it seems Apple is listening.

Today I’d like to go on the record with a list of features and options I’d like to see in a future version of iOS. I’m not typically huge on lists or “feature request” (last one was a series of predictions for WWDC ‘11), but I believe it’s worth discussing the direction where Apple is headed with its mobile operating system and, while we’re at it, propose solutions to improve existing apps and system utilities. I’ll check back on this list after WWDC ‘12. Read more