This Week's Sponsor:

PowerPhotos

The Ultimate Toolbox for Photos on the Mac


Posts tagged with "mac"

Apple Hits Restart on Game Controller Support

It’s hard to believe it’s been nearly six years since Apple added game controller support to iOS. The big news at WWDC in 2013 was the iOS 7 redesign, but for game developers, it was rivaled by the announcement that third-party Made For iPhone (MFi) controllers were coming.

The game press and developers understood the potential of controller support immediately. Even though it wasn’t announced there, Chris Plante of Polygon declared controller support the biggest story of E3, the game industry trade show that was happening at the same time as WWDC. Plante imagined that:

If Apple finds a way to standardize traditional controls, every iOS device will become a transportable console. In a year, both iPhones and iPads will approach the processing power of the current-generation devices. Companies will have the ability to port controller-based games for the mobile devices in millions of pockets — an install-base far greater than they’ve ever had before.

Game industry veteran Gabe Newell, the co-founder of Valve, saw Apple’s entry as a big risk to companies making PC and console games:

The threat right now is that Apple has gained a huge amount of market share, and has a relatively obvious pathway towards entering the living room with their platform…I think Apple rolls the console guys really easily.

I was right there with them. iOS devices couldn’t match the power of a traditional console in 2013, but you could see that they were on a trajectory to get there. With the addition of controller support, Apple felt poised to make a meaningful run at incumbents like Sony and Microsoft.

It didn’t work out that way though. iOS’ controller support was rushed to market. Early controllers were priced at around $100, in part because of the requirements of the MFi certification, and they couldn’t match the quality of controllers from Sony and Microsoft.

As anticipated, controller support was extended to the Apple TV when its App Store launched in 2015. Initially, it looked as though Apple would allow game developers to require a controller. In the end, though, the company went an entirely different direction by requiring that games support the Apple TV Remote, a decision that complicated development and dumbed down controller integration to match the remote’s limited input methods. Apple changed course eventually, and now lets developers require controllers, but by the time of that change the damage had been done. Many developers had already lost interest in controller support. It didn’t help either that for a very long time, the App Store didn’t indicate which games were compatible with MFi controllers, leaving the void to be filled by third-party sites.

Last year, when I looked back at the history of games on the App Store for its tenth anniversary, I came away pessimistic about the future of games on Apple’s platforms. After a decade, I felt like we were still asking the same question that Federico posed in 2013:

Will Apple ever develop a culture and appreciation for gaming as a medium, not just an App Store category?

Sadly, Federico’s question remains as relevant today as it was six years ago. Still, I’m cautiously optimistic based on what’s happened in the past year. Part of that is the App Store editorial team’s excellent track record of championing high-quality games in the stories published on the App Store. Another factor is Apple Arcade, the game subscription service we still don’t know a lot about, but which appears designed to showcase high-quality, artistically important games.

The latest cause for optimism is Apple’s announcement at WWDC this past June that iOS, iPadOS, tvOS, and macOS would all support the Sony DualShock 4 and Bluetooth-based Xbox controllers when Apple’s OSes are updated this fall. The reaction from developers and other observers was a combination of surprise and excitement that was uncannily similar to the MFi announcement in 2013. Yet, the news begs the question: ‘How is this time any different?’ The answer to that question lies in how the new controllers work and the role they will play in Arcade.

Read more


NetNewsWire Review: The Mac RSS Client, Rebooted with a Solid Foundation for the Future

After Google Reader disappeared, a lot of people drifted away from RSS readers. For many, social networks like Twitter filled the void, leading some observers to declare the death of RSS. However, a funny thing happened in the aftermath of Google Reader’s demise. New sync services arose, and RSS readers flourished on iOS, where competition to provide users with new and innovative ways to read their favorite feeds has been fierce.

However, feed reader options haven’t been nearly as robust on the Mac. As I’ve noted before, many of my favorite RSS readers for iOS don’t have Mac counterparts, and those that do haven’t been developed with the same regularity we’ve seen on iOS. It’s into this landscape that NetNewsWire 5 launches today.

If you’ve been using RSS for any length of time, you’ve undoubtedly heard of NetNewsWire, but may not be aware of its long history. The app’s roots stretch back to 2002 with NetNewsWire Lite 1.0, which Brent Simmons developed. In 2005, the app was purchased by NewsGator, then Black Pixel bought the app in 2011.

Simmons began working on a new open-source RSS reader called Evergreen in 2015. But then in 2018, he reacquired the rights to NetNewsWire from Black Pixel, bringing the app back to where it started for the first time in 13 years.

NetNewsWire comes with a built-in set of feeds to get newcomers started.

NetNewsWire comes with a built-in set of feeds to get newcomers started.

NetNewsWire 5 is an all-new, free app rebuilt from the ground up using Evergreen’s code, but bearing the name of Simmons’ original feed reader. The time and hard work by Simmons and other contributors to the open-source project are apparent. NetNewsWire 5 is a thoughtfully-designed, fast app with powerful search. The app won’t be my primary Mac feed reader until it has more syncing options or the planned iOS version is released, but if your feed reading is limited to the Mac or you use Feedbin to sync your feeds to iOS, NetNewsWire is an excellent choice.

Read more


Swapping Dongles for a Dock: The OWC Thunderbolt 3 Dock

By limiting its laptops to Thunderbolt 3 and USB-C ports, Apple has been able to continue its relentless pursuit of thinness. That’s great when you’re on the go. However, if an Apple laptop is your primary computer, the number and lacking diversity of ports is problematic. When you’re back at home or work, connecting legacy USB-A devices, SD and microSD cards, and Ethernet and HDMI cables requires an array of often expensive dongles and cables that quickly fill up the available ports on your Mac.

When I commuted to downtown Chicago for work, I carried a 2016 MacBook Pro with me. At the end of the day when I returned home, I sat the laptop on my desk and plugged in a bunch of cables and dongles, which was a pain. Because I work from home now, I don’t use my MacBook Pro that way very often anymore, except in the summertime when that laptop becomes a testbed for the latest macOS beta. I’ve been trying to work on the macOS beta from a MacBook Pro as much as possible over the summer, and the experience has caused me to revisit the frustration of unplugging cables and dongles every time I want to leave my desk and work elsewhere.

I had been thinking about ways to improve my summertime beta setup when Other World Computing offered to send me its OWC Thunderbolt 3 Dock to test. I took them up on the offer, and having used it for a while now, I love the convenience of being able to connect everything to my MacBook Pro with a single Thunderbolt 3 cable. It’s not an inexpensive solution, but compared to the cost of purchasing multiple over-priced dongles, it’s not as extravagant as it might seem at first.

Read more



Marzipan: A Chance to Revitalize the Mac App Ecosystem

My annual practice of deciding which Mac apps qualify as ‘must-haves’ is always an interesting exercise. At the core of this reflection is a simple question: ‘Why?’ Why this app instead of another one? Sometimes it’s an app that stands out from its competitors, making the choice easy. Other times it’s a unique feature that fits well with the way I work. Most of the apps I include in my annual round-ups fit into one of those categories.

Last year though, too many apps fell into a couple of different, troubling categories. First, I tolerate a handful of underwhelming apps because they’re associated with services I like or which are essential to my work. Apps like Slack, Skype, and Trello fall into this category. Second, there are apps like Due and Reeder that I like, but either they don’t get much attention or have fallen behind compared to alternatives on iOS. Fortunately, these apps are still in the minority among the apps I use regularly. For every disappointment, there are apps like Things, Ulysses, MindNode, iA Writer, Screens, and Yoink that are not only a pleasure to use on macOS, but offer excellent iOS apps too.

Still, as I covered in the conclusion of my 2018 must-have Mac apps round-up, the exercise of going through the Mac apps I use left me with an uneasy feeling:

there’s an interesting contrast between what I consider must-haves on iOS and the Mac. On iOS, many of the apps I consider must-haves are compelling because of a single feature that sets one app apart from others or because it fits especially well with how I work. Too often that’s not the case on the Mac. I find myself explaining that I use a particular app because ‘it gets the job done.’ That’s because there are too few alternatives to some apps, which is a shame.

Mac apps are not in a state of crisis, but at the same time, the universe of Mac apps is not nearly as big or diverse as iOS. That’s not surprising given that the number of iOS devices in use is roughly 10x the number of Macs in use. As someone who works on and studies both platforms though, the trends are troubling.

Read more


(Don’t Fear) The Reaper

Apple needed to show developers that Carbon was going to be a real and valid way forward, not just a temporary stopgap, so they committed to using Carbon for the Mac OS X Finder. The Carbon version of Finder was introduced in Mac OS X Developer Preview 2, before Aqua was revealed; it acted a bit more like NeXT’s, in that it had a single root window (File Viewer) that had a toolbar and the column view, but secondary windows did not. At this stage, Apple didn’t quite know what to do with the systemwide toolbars it had inherited from NEXTSTEP.

[…]

It had taken Apple four years to find the new ‘Mac-like’, and this is the template Mac OS X has followed ever since. Here we are, eighteen years later, and all of the elements of the Mac OS X UI are still recognizable today. So much of what we think of the Mac experience today came from NEXTSTEP, not Mac OS at all. AppKit, toolbars, Services, tooltips, multi-column table views, font & color pickers, the idea of the Dock, application bundles, installer packages, a Home folder, multiple users; you might even be hard-pressed to find a Carbon app in your Applications folder today (and Apple has announced that they won’t even run in the next version of macOS).

Fascinating read by Steve Troughton-Smith on how Apple transitioned from NeXTSTEP to Mac OS X between 1997 and 2001. The purpose of this analysis, of course, isn’t to simply reminisce about the NeXT acquisition but to provide historical context around the meaning of “Mac-like” by remembering what Apple did when the concept of “Mac-like” had to be (re)created from scratch.

Apple is going to be facing a similar transition soon with the launch of UIKit on the Mac; unlike others, I do not believe it means a complete repudiation of whatever “Mac-like” stands for today. The way I see it, it means the idea of “Mac-like” will gradually evolve until it reaches a state that feels comfortable and obvious. I’m excited to see the first steps of this new phase in a couple of weeks.

Permalink

Bringing iOS Apps to the Mac Will Entail More Than Flipping a Switch

Craig Hockenberry of The Iconfactory has an in-depth look at the challenges developers, designers, and marketers will face bringing their iOS apps to the Mac. Although Marzipan may make it possible to simply flip a switch in Xcode to build Mac and iOS versions of an app simultaneously, it’s unlikely to be that simple in practice. As Hockenberry notes:

that build setting is just the first step on a long and complicated road. Good interaction doesn’t come for free.

That’s because user interactions are different between iOS devices and Macs and driven by multiple factors including differing input devices, screen sizes, and individual UI elements.

One of the many examples of design challenges that Hockenberry covers is moving from iOS device screen sizes to Mac screens:

The most obvious design element that will change as you move from iOS to macOS is the screen. If you’ve designed for the iPad, you already understand the challenges of a larger display surface and adapting your views as that size changes. It’s not easy work, but an alternative design that’s just “a big iPhone” is highly unsatisfying for a customer.

The Mac alters this scenario slightly because your app is presented in a window that’s resizable: you might be running with the constraints of an iPhone SE one moment and the expansiveness of an iPad Pro the next.

Hockenberry also raises concerns about how developers will make money from Marzipan apps if they are universal apps as is the case with the iPhone and iPad versions of many iOS apps:

It’s my opinion that Universal apps were the worst thing to ever happen for the iPad ecosystem. There’s no way for a developer to recoup the costs for new interactions and the extra work needed for more sophisticated apps. Apple makes it easier for a customer up front by offering a single download, but at the same time they make things worse because a Universal version of the user’s favorite app isn’t financially viable.

One thing’s for sure, change is coming to the Mac. For some, it will be exciting, and for others, it will be fraught with peril. Mistakes will be made, and adjustments will be necessary, but for iOS developers, designers, and marketers new to this sort of transition, Hockenberry’s post is a great place to start thinking about bringing their apps to the Mac. He’s been through similar changes in the past, and with the magnitude of what Apple likely has in store at WWDC, there’s no time like the present to start considering these issues.

Permalink

A Mac Automation Schism

Thoughtful take by Jason Snell on the recent discussion around the idea that Shortcuts may be coming to the Mac and what that could mean for macOS automation. Snell imagines a scenario where Quick Actions, introduced last year with Mojave, could act as a bridge between old-school Mac apps and a new breed of Marzipan apps compatible (in theory) with Shortcuts only:

Something funny happened in macOS Mojave. Apple actually brushed off some very old Mac OS X technology, Services, and gave it a rebrand as Quick Actions. Quick Actions are commands you can find in Quick Look previews, the Finder’s new Gallery view, and on the Touch Bar. Some are pre-built by Apple, but users can add their own by saving Automator actions as Quick Actions.

I have no idea what prompted Apple to bubble up Automator actions into more places in the macOS interface with Mojave, but Quick Actions strikes me as a pretty good companion to Siri Shortcuts. Imagine a scenario where apps originating on iOS can support Siri Shortcuts via the same methods they use on iOS. Now imagine that Siri Shortcuts can also use Quick Actions as a source for potential commands. Quick Actions are contextual, those old-school Mac apps can bring their own Quick Actions to the party, and users can build their own Quick Actions to do whatever they want. It would be a simple way to bridge the gap between the two different app types that Mac users will be using together, at least for a while.

As I argued on Connected a couple of weeks ago, I’m intrigued by the idea that a Mac version of Shortcuts could have built-in bridges for old automation tools (shell, AppleScript, Automator, etc.) to at least trigger those scripts from the new app. Quick Actions would be a great fit for this; in fact, I find the whole idea of Quick Actions is well suited the Files app on iOS as well.

Permalink

Using a Mac from iOS, Part 2 – Luna Display and macOS as an App

iPad Diaries is a regular series about using the iPad as a primary computer. You can find more installments here and subscribe to the dedicated RSS feed.

In the first part of my ongoing experiment with controlling and accessing a Mac from the iPad Pro, I covered FileExplorer – the app I use to open Finder locations from iOS’ Files app – and shared a collection of shortcuts to control certain macOS features via Siri and the Shortcuts app. I also described my podcasting setup and how I’ve been taking advantage of Keyboard Maestro to automate window resizing across my two displays connected to the Mac mini. Today, I’m going to cover one of those two external displays – the iPad Pro running the Luna Display app – and how I’ve been using it to have “macOS as an app” on my iPad Pro. If you find this idea of reducing macOS to an app that runs on the iPad upsetting, the rest of this article likely isn’t going to make you happy. If you’re intrigued, however, strap in because I have a lot to share.

Read more