Federico Viticci

10865 posts on MacStories since April 2009

Federico is the founder and Editor-in-Chief of MacStories, where he writes about Apple with a focus on apps, developers, iPad, and iOS productivity. He founded MacStories in April 2009 and has been writing about Apple since. Federico is also the co-host of AppStories, a weekly podcast exploring the world of apps, Unwind, a fun exploration of media and more, and NPC: Next Portable Console, a show about portable gaming and the handheld revolution.
@[email protected]
@viticci.macstories.net
viticci@macstories.net

Unread for iPad Review

I first reviewed Jared Sinclair’s Unread, a fast and elegant RSS reader for iPhone, when it came out in February, making it my go-to RSS app on my Home screen:

I approached Unread thinking that it was an app designed for people who subscribe to a handful of feeds and just want to read a few articles every day. What I found is an app that works exceptionally well with hundreds of feeds, that has great custom typography and interface choices that don’t look out of place on iOS 7, and that tastefully implements modern gestures, sharing controls, and iOS technologies.

For me, Unread provides a better reading, syncing, and sharing experience than Reeder. While it lacks some of the features that Reeder gained over the years, Unread’s debut shows an app with focus, flexibility, attention to iOS 7, and the capability of scaling from dozens of unread items to several hundreds articles. Some people will complain about the lack of a compact mode to disable article previews in the main list; combined with thumbnails, I realized that this feature helps me pay more attention to articles in my RSS feeds.

Today, Sinclair has released Unread for iPad, a new version of the app sold at $4.99 on the App Store. Unread for iPad is heavily influenced by its iPhone counterpart, and fans of the iPhone version will be instantly familiar with it.

Read more

Explaining iOS 8’s Extensions→

If you’re looking for a more technical overview of extensions in iOS 8, Andrew Cunningham has a great one at Ars Technica:

A simple way to summarize all of this: Apple doesn’t want one app to be able to get into another app’s sandbox. Extensions are like little sandboxes-within-sandboxes that facilitate communication between different apps while never sharing all of their containing app’s data directly with the host app.

It’s good to know that Apple is making iOS more flexible and powerful while keeping an underlying model designed for security, performance, and user control.

One of the questions I’ve received over the past few days is whether enabling a lot of extensions in iOS 8 could cause issues similar to the ones found in, for instance, Safari for OS X with multiple browser extensions installed. Based on what Apple has shown, the answer shoule be “no”: the technology is different, extensions will run in separate sandboxes, many of them will be user-triggered, and iOS will check memory usage and stop them if necessary (as Andrew notes, older devices will likely suffer for this).

It’ll be interesting to see how developers will take advantage of extensions this Fall.

Permalink

UI Workflows for Editorial→

Since my review of Editorial 1.1, I’ve been keeping an eye on the workflow directory and I’ve come across some great UI workflows worth linking to.

  • Crop Image: “Custom UI to crop images and save the output to the Camera Roll” (More details by Philip Gruneich in his blog post. I love this idea.)
  • Move Line: “Indent, outdent or move line up/down using arrows in popover UI”
  • Sidebar Notes: “Shows a “Notes” sidebar next to the document (on iPhone, it’s shown in an accessory panel instead of a sidebar)“
  • List Folder: “Shows a popover with a list of files in a configurable folder”

Editorial users are coming up with amazing ideas to enhance the app, and I can’t wait to see what Ole does with extensions on iOS 8.

Permalink

JavaScript for Automation on OS X Yosemite→

As detailed by Apple in a technical document, OS X Yosemite will add JavaScript support for scripting and automation:

The JavaScript OSA component implements JavaScript for Automation. The component can be used from Script Editor, the global Script Menu, in the Run JavaScript Automator Action, applets/droplets, the osascript command-line tool, the NSUserScriptTask API, and everywhere else other OSA components, such as AppleScript, can be used. This includes Mail Rules, Folder Actions, Address Book Plugins, Calendar Alarms, and Message Triggers.

From the developer session video’s description:

With OS X Yosemite, application scripting support has been added to another popular language, JavaScript. JavaScript for Automation (JXA) extends the standard JavaScript environment provided by the JavaScriptCore framework with support for querying and controlling all of the scriptable applications running in OS X. JXA scripts are supported at all layers of the system and can be invoked from the command-line, from the system-wide Script Menu, and can even be distributed as code-signed applications.

This is an interesting change for automation on OS X going forward, and JavaScript will be available alongside AppleScript in the Script Editor. You can watch the session video “JavaScript for Automation” here or in Apple’s WWDC app.

Permalink

Apple’s Advantage→

Kyle Baxter, writing about Apple’s Health app and HealthKit, both announced at WWDC:

Second, Apple takes this relationship very seriously. iOS makes it very clear when applications are requesting access to our personal data. Apple has worked quite hard to make sure that the user decides what and how much they want to share.

I don’t think Google or Facebook could announce that they are going to collect their users’ health data and optionally send it to their doctors without some reasonably large amount of criticism and fear of abuse. The reason is obvious: their primary business is utilizing user data to generate revenue, so why couldn’t they do the same with health data?

I agree. Apple highlighted the importance of user privacy several times during the keynote, and I appreciated many of the tech-related choices behind that – such as disabling network access for third-party keyboards by default.

Permalink

OS X Yosemite Beta UI Compared to Mavericks→

Min Ming Lo has published a good initial comparison of the OS X Yosemite beta UI compared to Mavericks:

Apple revealed a sneak peek into Mac OS X Yosemite earlier this week. Not surprisingly, Apple updated its desktop OS to match iOS 7’s design language. The new OS X now embodies a brighter and flatter styling, coupled with icon updates, font changes, and translucent materials. Here’s a quick look at the visual design changes in Yosemite and my impressions of them.

Clearly Apple has a lot of work ahead to polish Yosemite before the final release, but I’m a fan of the new direction. And, unlike others, I’m glad to see a happier Finder. Who doesn’t like smiles?

Permalink

Brent Simmons’ Early Thoughts on WWDC 2014→

Brent Simmons:

It was like this, though — we kept hearing about things, even relatively small things, that all by themselves would have made for a great week. It was like the greatest Christmas ever — and then Santa Claus hung out so you could take selfies with him. This friendly and generous Apple reminds me why I love writing iOS and Mac apps.

It’s a small thing, but I think the photos that Cook, Federighi, and Ive took with developers make Apple feel more human and approachable. Combine that with great announcements, and you get a fantastic WWDC.

Permalink

iOS 8 Extensions: Apple’s Plan for a Powerful App Ecosystem

Amidst the variety of announcements from WWDC 2014, Extensibility – a new set of technologies for developers to extend their apps – has been mainly regarded as Apple’s solution to the lack of inter-app communication on iOS.

Traditionally, iOS has been a closed platform in terms of software personalization and extensibility: due to a combination of design choices and strict enforcement of sandboxing rules, iOS users never enjoyed many of the benefits found on Google’s mobile operating system. Android users could, for instance, install system-wide replacement keyboards or pick documents from any app advertised as a storage location; iOS users, on the other hand, were forced to deal with unnecessary copies created by an outdated Open In system or stick with Apple’s dubious keyboard design in iOS 7.

Simultaneously, with Apple focusing on Maps improvements and a new design foundation for iOS, a few third-party developers took up on the task of creating apps and protocols capable of extending iOS as much as possible leveraging the tiny holes left by Apple in its sandbox.

We’ve seen a proliferation of apps that use URL schemes to facilitate the process of launching other apps and passing text to them; bookmarklets – pieces of JavaScript code executed in the browser – to let Safari communicate with third-party apps; developers creating their own SDKs and app ecosystems to solve document management; Fleksy – a popular Android keyboard – making an iOS SDK; a Python interpreter and a text editor with a workflow automation system, developed by a one-man shop in Germany.

The third-party iOS development community has been incredibly creative in spite of Apple’s longstanding limitations on iOS, but many of the devised solutions – especially URL schemes – were, ultimately, hacks and workarounds based on a protocol that wasn’t intended to let multiple apps communicate and exchange data.

With iOS 8, Apple wants to make iOS more flexible and powerful by letting developers extend custom functionality and content beyond their apps, making it available to users in other parts of the OS – and all while maintaining a secure design model, user privacy, good performance, and battery life.

As someone who’s invested in iOS as a productivity platform and uses the iPad as a primary computing device every day, I welcomed Apple’s move with excitement and optimism, but I also wanted to investigate the actual scope of the technology the company will ship later this year.

Read more