Tag
Cocoa
Articles and publications tagged Cocoa across the Atmosphere.
40articles1publication
Articles
Publications
New edition of the "Guide to NSButton styles"
Note (Oct 2023): The names of the buttons have been changed again in the SDK in macOS Sonoma - I will update the blog post again once I have Sonoma on one of my Macs :)
Back in October 2014 I wrote a post about different styles of NSButtons.
That was in the era of OS X Yosemite and Xcode 6. I started researching what each kind of button available in Interface Builder was for, because I couldn’t figure that out from Xcode and the built-in documentation - I dug a bit into the Human Interface Guidelines, some older documentation archives and into Apple apps themselves. I collected everything into a long post that went through all the button styles and described what I could find about each one.
It seems that a lot of people also had the same problem, because the post turned out to be extremely popular. It’s around #3 in total page views on this blog, and 7 years and 7 major macOS versions later it still usually comes out #2 in monthly or yearly stats and still gets a couple hundred visits a month. Even with greatly improved documentation in Xcode and much expanded content in the modern HIG, there’s clearly demand for this kind of information collected in one place.
However, the post was kind of asking to be updated for a long time now… The original screenshots were made in 1x quality, since I didn’t get a Mac with a Retina screen until the end of 2016. Big Sur was released in the summer of 2020, significantly changing the design of the OS, and making Catalina suddenly look outdated (to the point that I’ve seen some people already call the Yosemite-Catalina era design “classic macOS”!). Some new button variants were added, some older buttons were no longer used in system apps the way I presented them, and the button styles available in Xcode were no longer shown and described as shown on screenshots from Xcode 6.
The Big Sur launch seemed like a great moment to give that post a refresh, and I started working on it at the end of last year, but then 2021 came and this year turned out to be kind of rough - surprisingly more so than 2020… as it was for a lot of people, I suppose. I only managed to get back to this project this month.
I thought it would take maybe a week or two… it took around three in total 😬 That included setting up new Mavericks and Yosemite installations in VirtualBox to get updated Retina screenshots from there, building a number of versions of a sample app full of all kinds of buttons that I took a ton of screenshots of on several macOS versions, cutting every screenshot pixel-perfect to size a few times, merging different versions of the same information from a few different sources, including versions of HIG going as far back as 2006, looking through Apple apps searching for buttons, and view-debugging some of them with SIP turned off to check what controls were used there… whew 😅
I’m really happy with the result though. This is now by far the longest post on the blog, with around 11k words total (although around 1/3 of tha…CocoaMac
WatchKit Adventure #4: Tables and Navigation
< Previously on WatchKit Adventure…
Two weeks ago I posted the first part of a tutorial about how to build an Apple Watch app UI using WatchKit, using a WKInterfaceController and a storyboard. We’ve built the main screen for the SmogWatch app, showing a big colored circle with the PM10 value inside and a chart showing data from the last few hours.
Here’s the second part: today we’re going to add a second screen that lets the user choose which station they want to load the data from. So far I’ve used a hardcoded ID of the station that’s closest to me, but there are 8 stations within Krakow and the system includes a total of 20 in the region, so it would be nice to be able to choose a different one.
(I initially wanted to also include a selection of the measured pollutant - from things like sulphur oxides, nitrogen oxides, benzene etc. - and I’ve actually mostly implemented it, but that turned out to be way more complex than I thought, so I dropped this idea.)
The starting point of the code (where the previous part ends) is available here.
Preparing the data
Since the list of stations doesn’t change often, we can hardcode a list of stations with their names, locations and IDs in a plist file that we’ll bundle inside the app. The list is generated using a Ruby script, in case it needs to be updated later - you can just download the plist and add it to the Xcode project.
At runtime, the list will be available in the DataStore:
struct Station: Codable {
let channelId: Int
let name: String
let lat: Double
let lng: Double
}
class DataStore {
// ...
lazy private(set) var stations: [Station] = loadStations()
private func loadStations() -> [Station] {
let stationsFile = Bundle.main.url(forResource: "Stations", withExtension: "plist")!
let data = try! Data(contentsOf: stationsFile)
return try! PropertyListDecoder().decode([Station].self, from: data)
}
}
Handling secondary screens
When we want to add an additional screen to the app that shows some secondary information or less commonly used feature like this, there are generally three ways we can handle it:
we can add an explicit button somewhere on the screen that opens it (usually in the bottom part)
we can put it on another page in the page-based layout (e.g. like sharing and awards in the Activity app)
or we can put it as an action in the menu accessed through Force Touch
The third option (Force Touch menus) is going away now. In the watchOS 7 betas, Apple has removed all Force Touch interactions from the OS and their own apps, the APIs for using it in third party apps (addMenuItem in WKInterfaceController) are deprecated, and it’s highly likely that the upcoming Series 6 watch will not include it as a hardware feature.
Hiding some actions in a menu had the advantage that it didn’t clutter the main view, but it also made those actions less discoverable and harder to use for those who need them. I personally always had a problem wit…CocoaWatchKit
WatchKit Adventure #3: Building the App UI
< Previously on WatchKit Adventure…
This is the third part of my series about building a WatchKit app that shows current air pollution level on the watch face (it started here). In this episode, we’re going to build the app’s main UI. I will be building on top of some data handling & networking code written in the previous episode about complications, so if you haven’t seen that one, you might want to at least skim through it to get some idea about what this is about. Browse through the WatchKit category to see the whole list.
We’re venturing into a somewhat uncharted territory now… The WWDC talks about WatchKit are an amazing source of information and they’re great to get started (I definitely recommend watching them, especially the earlier ones, from 2015 & 2016), but once you actually start building things and run into a problem, there’s surprisingly little help available. Even StackOverflow isn’t of much use. There aren’t many books out there either that are up to date - I got one from raywenderlich.com, but it doesn’t really answer the hard questions, and it wasn’t updated since watchOS 4; Paul Hudson has another, and that’s pretty much it.
I’ve tried to figure out some things myself, but some questions are left unanswered. If you know how to solve anything better than I did, please let me know in the comments.
The two frameworks
watchOS SDK launched first in 2015 with a new UI framework called WatchKit. It was a very different framework than what we knew from macOS and iOS, a framework specifically designed for the Watch and all its inherent and temporary limitations - and also limited in what it could do and what you could do with it. It got people excited, but also very quickly frustrated, once they’ve run into these limitations. It didn’t help that Apple’s own apps were very obviously doing some things in the UI that weren’t possible to external developers, clearly using some internal APIs Apple needed to build more powerful apps, but which they didn’t want to share with us.
So of course the hearts of Watch developers started beating faster when we heard the brief mention “… and a new native UI framework” during the 2019 keynote - said almost as if we were supposed to miss it. Of course about two hours later we’ve learned that this new framework was SwiftUI, built not only for watchOS (although that’s how the whole thing started, apparently!), but for all Apple platforms. A thing that would completely change Apple platform development.
However, as people who have rushed to try out this new framework quickly discovered, SwiftUI as released in the iOS 13 SDK was “a pretty solid version 0.7” - a massive step forward of course, especially on watchOS, but still more of a beta. The “version 2.0” released this June seems like a very decent update, but it’s not stable yet and at this point it’s still unclear if it solves most of the issues that people had with the first release.
So here we are, with two frameworks, an old one that’s ver…CocoaWatchKit
SwiftUI betas - what changed before 1.0
In the last few weeks I’ve been trying to catch up on SwiftUI - watching WWDC videos, reading tutorials. Not the new stuff that was announced 2 months ago though - but the things that people have been using for the past year.
Last June, like everyone else I immediately started playing with SwiftUI like a kid with a new box of Legos. In the first month I managed to build a sample Mac app for switching dark mode in apps. However, after that I got busy with some other things, and never really got back to SwiftUI until recently, so by the time the “version 2” was announced at the online-only WWDC, I’ve already forgotten most of it. So in order to not get this all mixed up, I decided to first remember everything about the existing version, before I look at the new stuff.
Back then, when I was watching all the videos and doing the tutorial, I was taking a lot of notes about all the components, modifiers and APIs you can use, every single detail I noticed on a slide. However, I was surprised to see how many of those things I wrote down don’t work anymore. After the first version that most people have played with and that the videos are based on, there were apparently a lot of changes in subsequent betas (especially in betas 3 to 5). Classes and modifiers changing names, initializers taking different parameters, some things redesigned completely.
And the problem is that all those old APIs are still there in the WWDC videos from last year. But WWDC videos are usually a very good source of knowledge, people come back to them years later looking for information that can’t be found in the docs, Apple even often references videos from previous years in new videos, because they naturally can’t repeat all information every year.
This was bothering me enough that I decided to spend some time collecting all the major changes in the APIs that were presented in June 2019, but were changed later in one place. If you’re reading this in 2021 or 2022 (hopefully that damn pandemic is over!), watching the first SwiftUI videos and wondering why things don’t work when typed into Xcode - this is for you.
Here’s a list of what was changed between the beta 1 from June 2019 and the final version from September (includes only things that were mentioned in videos or tutorials):
NavigationButton
Appeared in: “Building Lists and Navigation” tutorial, “Platforms State of the Union”
ForEach(store.trails) { trail in
NavigationButton(destination: TrailDetailView(trail)) {
TrailCell(trail)
}
}
Replaced with: NavigationLink
ForEach(store.trails) { trail in
NavigationLink(destination: TrailDetailView(trail)) {
TrailCell(trail)
}
}
PresentationButton / PresentationLink
Appeared in: “Composing Complex Interfaces” tutorial, “Platforms State of the Union”
.navigationBarItems(trailing:
PresentationButton(
Image(systemName: "person.crop.circle"),
destination: ProfileScreen()
)
)
Replaced with: PresentationLink, which was lat…CocoaiPhone
Photo library changes in iOS 14
I’m the kind of person who cares a lot about their digital privacy. It makes me very uncomfortable when I see ads on Facebook for something I opened on another site a moment ago, and I generally don’t like it when companies are learning more about me than they should, even if the effects of that tracking aren’t as obvious.
That’s why for example I’ve been trying to move away from Google services as much as possible (I use ProtonMail as my main email and Apple’s iWork for documents), I also started using Tresorit and iCloud1) for file sync instead of Dropbox. That’s also one of the reasons why I’ve always used some kind of ad & tracker blocker in my browsers - previously Ghostery, now I also use Brave and I’ve been experimenting with making my own ad blocker.
So it always makes me happy when Apple introduces another change to their OSes that limits the kinds of data that Mac and iOS apps can use without our permission. I especially liked:
when iOS 11 introduced the “While Using” option for location access that was non-optional for apps
the “Allow Once” option for location access in iOS 13
permissions to things like camera, microphone or screen recording on the Mac
This year Apple made another batch of changes that limit apps' access to data. The most interesting ones are the approximate location access and the limited photo library - in this post I’ll talk about the latter.
Most of us have thousands of photos on our phones, often going a few years back - after all, our iPhones are our primary cameras these days. These photos and videos capture everything we do, the places we go to, who we meet with and what we do together. They also include location info in their metadata. This is all possibly extremely sensitive data.
So far however if you wanted to upload a single photo or screenshot to e.g. Twitter or Facebook or send it to a friend through a messaging app, you had to grant them access to your whole photo library - it was all or nothing. And you could never be sure what they do with it - are they just looking at this single picture, or maybe looking through your whole 30 GB library for any interesting stuff they can find there, and uploading that to their servers? Hopefully they aren’t, but you just had to trust them on this.
Apple had previously provided a system image picker (UIImagePickerController) that lets the user choose a photo from their library and pass it to the app without giving it access to the library, as well as a way to save photos to the library without seeing what else is there (UIImageWriteToSavedPhotosAlbum()). However, for various reasons these don’t seem to be widely used in popular apps - most apps that do anything with photos currently ask for full read-write access to the whole library, just because they can.
So this year Apple is taking a bit of a carrot and stick approach: the carrot is a new improved system photo picker, while the stick is a new way for the user to only give the app access to selected photo…CocoaiPhone
Notes from WWDC
When I watch conference talks, I like to take notes - either on an iPhone or iPad when I’m in the conference room, or on the Mac when I’m watching online like in case of WWDC (I’ve never seen it in person). It makes it easier for me to remember the most important content from the presentation, and especially in case of WWDC notes I often come back to them to find some specific piece of information - WWDC talks are a very important part of documentation of how to use Apple’s APIs, sometimes (sadly) the only piece of documentation about the specific class or method that’s available.
I have a fairly large archive of those notes (around 20 from each year on average), usually just stored as one long note in the Notes.app, and I’ve been thinking for a while that it could make sense to somehow share them with the world. I have no idea how useful they will be for others, since I write them primarily for myself, they’re much more condensed than blog posts and basically written as just a “diff” from what I knew before, but I guess I won’t know until I try.
One problem I had with sharing the notes is that they’re written as completely plain text, something like this:
If I wanted to convert each note to proper Markdown, it would be a lot of manual work, and I didn’t really feel like doing that. So one day I had an idea: I could write some kind of parser that renders those notes as they are written, with some minimal changes, into something that looks as if it was rendered from Markdown.
It was a pretty fun challenge - involving some large number of regexps straight from hell, for detecting all the code fragments automatically - but in the end, the result is better than I expected:
For now, I’ve added all my notes from last year’s WWDC - you can view them as one page with all contents or as an index of titles. I was planning to add some older ones too, but I ran out of time. I’m planning to add notes from the current WWDC as I watch the videos - you will be able to see them here :)
RSS feeds
I’ve also updated my RSS (Atom) feeds - there are now 3 separate feeds:
main blog feed (with classic long posts): https://mackuba.eu/feed.xml
notes feed: https://mackuba.eu/feed-notes.xml
complete feed with both posts & notes: https://mackuba.eu/feed-all.xml
Previously I’ve been using a FeedBurner proxy URL for the feed. If you’re reading this through your feed reader app, check what URL you’re subscribed to - if you’re subscribed to the FeedBurner one, please update it to the direct link from above (blog feed or complete) - the FeedBurner one probably won’t work forever (Google bought the service long time ago, and you know what happens to services that are bought by Google).CocoaMac
I'm building an ad blocker
Since my update to the iOS version of Banner Hunter was rejected by app review, the app’s been in a kind of Schrödinger state, both dead and alive. It’s still selling those few copies a week, and I’m updating the blocklist, but I’m afraid to make any updates to the Mac app now… So since then I started looking for some other ideas for new apps I could build instead.
One thing I started working on is a Chrome version of Banner Hunter. I wasn’t really planning to do it before, but since Apple pushed me now… I might as well give it a try. I have no idea if it’s possible to make any money on Google Store, since the vast majority of extensions are free, but we’ll see. The main part of the app is done, but I need to work on the non-technical parts like graphics and copy, and it will probably have to wait until late summer at least.
I’ve got another idea though which has kind of come up by itself, which is… to build an ad blocker for Safari.
(TLDR: here’s the landing page.)
Researching the options
I’ve been a long time user of Ghostery before, since it was closest to what I want from an ad blocker and it worked well. But since I upgraded to Catalina and Safari 13, I had to finally let go of the old Ghostery extension, and the new “Ghostery Lite” is just not as good as the old one. So I started looking for alternatives.
Turns out, there aren’t really that many good, reputable, popular ad blockers on the Mac App Store - I think it’s easily a single-digit number. I’ve tried a few, but I wasn’t completely happy with any of them. That doesn’t mean they’re not objectively good - they should work fine for a lot of people, possibly most people - but it’s just not what I personally want.
Here’s what I want from an ideal ad blocker:
it should mercilessly block any unnecessary code loaded from external sources that slows down page load and sends tracking cookies who knows where - this conveniently blocks almost all ads, but it should also block any non-ad things that spy on me (like Google Analytics or Facebook tracking pixels)
it should NOT try to globally block any resource and any div on any page that includes the word “ad”, “banner”, “popup” etc. - I believe this makes it way too easy to hit false positives and randomly break some innocent sites in the process (and it seems to be much easier to detect for anti-adblockers, which usually create a “bait” div that screams “this box is an ad, block me!”); but unfortunately most public ad lists seem to work this way
it should not try to do so much that it becomes bloated in some way, or needs to be split across several separate content blockers, etc.
it should allow some basic configuration like site whitelisting
it should have a native look & feel
Most of the apps I’ve tried were either doing way too much for me (e.g. 1Blocker - 8 content blockers and requires a subscription, Wipr - 3 blockers) or too little (Ka-Block - just ~500 rules, or Wipr’s no whitelisting by design), often also didn’t look right in t…CocoaMac
SwiftUI quotes
I was going through some saved links and open tabs from June recently while finishing the WWDC collection post. I found a lot of interesting quotes about SwiftUI, Catalyst and the future of Apple platform development, and I decided to steal the idea from @mjtsai and put them together in one place. It might be interesting to look at this 5 or 10 years from now…
First impressions
Paul Hudson:
“Whole SwiftUI programs fit into tweets 🤯”
Paul Hudson:
“Having now built half a dozen apps using SwiftUI, I can say one thing for sure: going back to UIKit feels like going back to Objective-C. So, be warned – if you dip a toe in SwiftUI you’ll find yourself groaning when you head back to UIKit!”
Jeff Nadeau:
“I have *never* written a UI for any platform faster than I have with SwiftUI. And I was working with the unfinished version.”
Samuel Giddins:
“SwiftUI is legit. I’ve played around with it for about 15 minutes having skipped over most of the docs, and I have a functioning skeleton app. This would’ve been about 10 files and 200 lines of boiler plate 5 years ago. A tip of the hat to friends who build this amazing future”
“Incidentally, this is roughly the first time in 5 years where I feel any urge at all to work on an iOS app from scratch. Seriously, this is exciting stuff!”
“We’ll probably be using it for 10+ years, I’m glad it doesn’t come encumbered with baggage to allow backwards-deploying it for a single years worth of releases”
How it will change Apple platforms
Brent Simmons:
“I’m surely not the only person to think, all week long, that this WWDC marks the end of Apple’s NeXT era and the beginning of the Swift era.”
“It’s early. It has bugs. It’s not nearly complete. Sure. But it’s also how we’re going to write apps in the future.”
“It may be a while before you’re running apps that use SwiftUI and Combine (and who knows what else still to come). We’re in a transition, and transitions take years. But we’ve all just had a glimpse of the next 20 years.”
Wil Shipley:
“Apple announced a lot of stuff today but the the most amazing thing was kind of low-key — SwiftUI is a new way to write code for all their platforms simultaneously that’s incredibly efficient and uses modern programming practices. This is a revolution for Mac programmers.”
“All of us Mac-heads have been bracing for iOS UIKit to get shimmed into the Mac and we’d have to learn that, because it’s crazy for Apple to have two UI frameworks. And we got that today…but we also got a THIRD framework, which both obviates and unifies the existing two!”
“I thought eventually, if we were lucky, we’d get a new UI framework that was Swift from the start and cross-platform, but I did NOT expect it for years and years. I am blown tf away.”
Craig Hockenberry:
“Don’t underestimate what is going on here: I haven’t been this excited about how we make products since the Carbon to Cocoa transition.
This is an absolutely fundamental change that we’ll be using for decades.”
Daniel Jalku…CocoaiPhone
New stuff from WWDC 2019
As I’m writing these words, it’s the last day of November and the temperature has just dropped to close to 0°C here in Poland. But let’s move back to a better time for a moment, to the first days of June - the long days of warm sunny weather, inviting you to spend some time outside… and the huge pile of new stuff that Apple had just dropped on us on the WWDC keynote day, inviting you to try to frantically read and watch everything at once, and don’t leave the computer until you’ve read it all.
For the past 4 years I’ve been trying to cope with this crazy period by collecting notes from the WWDC talks, release notes, saving tweets, links to blog posts and so on, and organizing it all in a single ordered blog post. Writing things down this way is how I learn best, it helps me put together all loose pieces of information into a single picture, and gives me the peace of mind that I haven’t missed or forgotten anything important.
I usually finish this by July, but this year was different - first I got really hooked on SwiftUI and spent some time doing some experiments with it, and then I was busy working on and releasing my iOS content blocker app and doing some travelling. It didn’t help that the sheer amount of new APIs added this year was simply overwhelming.
So I finally got back to this in November, and I’m posting the list here on the half-anniversary of the 2019 keynote (yes, it’s really been 6 months already!) - hopefully it will still be of use to you.
Previous editions are available here - I’ve also done some slight formatting changes here and there, and updated the links to point to Web Archive 🗄️ versions if the page no longer exists or was overwritten:
WWDC 2018
WWDC 2017
WWDC 2016
WWDC 2015
Quick links:
macOS 10.15 • iOS 13 • watchOS 6 • tvOS 13
Shared Frameworks • macOS 10.15 SDK • iOS 13 SDK • watchOS 6 SDK • tvOS 13 SDK
Web APIs & Android • Developer Tools • Safari 13 • Other
macOS 10.15 Catalina
https://www.apple.com/macos/catalina/
https://www.apple.com/macos/catalina/features/
Find My app (Catalyst-based)
combines “Find My iPhone” and “Find My Friends”
can find devices that are offline and in sleep mode - communicates through other devices nearby (article)
iTunes is split into:
Music app (includes iTunes Store)
Podcasts app (Catalyst-based)
TV app
device syncing section in Finder
redesigned Reminders app
Screen Time for Mac (it has some problems though)
Sidecar - using iPad as a second display, iPad with a pencil can act as a drawing tablet
App Store:
Apple Arcade section
Mail:
“classic layout” of the window (email contents below) and classic look of the email list (narrow rows with columns) are now two indepedent settings in the View menu
option to block emails from specific senders
muting notifications from specific threads
button for unsubscribing from newsletters in the email header
Maps:
completely rebuilt, much more detailed map content - entire US by the end of 2019, some other countries next year
Not…CocoaiPhone
SwiftUI on AppKit: Building a Dark Mode switcher
I spent a large part of last week learning and playing with SwiftUI. So far it’s been pretty frustrating at times since I kind of feel like I forgot everything I knew, but I’m also very excited about where this will lead us. I’ve summed up my first impressions in the “Thoughts on SwiftUI” post last week.
At the moment most of the available examples show how to use SwiftUI in iOS apps, but I wanted to see how it would work on the Mac (in AppKit), since it’s kind of closer to my heart (hint: look at the domain name :).
And I had an idea: last year, when I was playing with the new Dark Mode in macOS Mojave I had a plan to build a simple app that would let you override the appearance in specific apps using the NSRequiresAquaSystemAppearance setting. I started working on it, but I got stuck while figuring out the complex NSTableView API which I had no experience with, and I gave up.
So, how about I give it another try now, but with SwiftUI? I don’t really need such app myself (I only use light mode), and I’m pretty sure I’ve seen other similar apps last year, but this seems like a perfect way to try out SwiftUI on the Mac - and to see if it will be easier to get the table view to work…
Update 15.08.2020: I’ve updated all code to work with the latest (stable) version of SwiftUI, adapting it to all the changes that were made to the API in last year’s later betas.
mackuba ∕ DarkModeSwitcher
Simple app for overriding light mode per app on macOS (demo for a blog post)
Building the app
In order to build a SwiftUI Mac app in Xcode, you need to have the beta version of macOS Catalina installed - SwiftUI will not work on Mojave. This is the first beta and some people have had serious issues with it, so be careful and don’t install it on your main computer. If you want to play with SwiftUI in UIKit, you can use this trick to make it run in a playground on Mojave, but it doesn’t work for AppKit.
And one more thing to note - Apple has unfortunately removed any remaining ways to force the dark mode per app in one of the later Mojave betas. The only thing we can still do (so far) is force the light mode if the rest of the system uses dark mode.
So, let’s begin. First, we’re going to need a list of all installed apps. Let’s define an app model:
class AppModel {
let name: String
let bundleURL: URL
var icon: NSImage?
var bundleIdentifier: String?
var requiresLightMode: Bool = false
init(bundleURL: URL) {
self.name = bundleURL.deletingPathExtension().lastPathComponent
self.bundleURL = bundleURL
}
}
We’ll store the list of apps in a list manager called AppList. We’ll make it an ObservableObject so that the UI can subscribe to updates in apps, and we’ll use @Published to send updates whenever the app list changes:
class AppList: ObservableObject {
@Published var apps: [AppModel] = []
}
The AppScanner class will take care of finding and returning the inst…CocoaMac
Thoughts on SwiftUI
Like everyone, I was shocked by Apple’s surprise reveal of SwiftUI at WWDC last week. We’ve heard rumors of some kind of declarative, multi-platform framework coming sometime in the future, but I don’t think anyone expected we’d see it so soon. This seems like a huge change, a beginning of a completely new chapter for app developers on Apple platforms. I’ve watched most of the session videos about SwiftUI and I’m incredibly excited and eager to start using it in practice.
Here are some first impressions and thoughts about SwiftUI after reading about it and playing with it for a few days:
Difficulty:
Prepare to feel like you’ve just started learning Mac/iOS programming… This is a completely new thing which works in a completely new way, and it’s hard to switch your brain to a new mode. You will be thinking “How the hell do I do X” every step of the way. And it’s ok, because even ignoring the paradigm change, this is just a completely new API, we don’t know the names of all the classes and methods by heart and it will take time before we’re somewhat familiar with them.
We’ll need to figure this thing out together - over the next months there will be thousands of blog posts, tutorials, books, screencasts and conference talks. People sharing tips, techniques and best practices. This will make it much easier to learn how to use these new APIs and how to do it well. (Some crazy people have already started last week!)
Things I’ve had the most trouble with so far:
layout, whenever it goes beyond the simple horizontal or vertical flow - how to put this thing in that place or make sure it has such size - things that would be trivial with AutoLayout, here I often don’t even know where to start
bindings - which kind of property to use and how, where to use the ‘$’, how to make sure the UI gets notified of a given change (or even how to get the thing to compile at all)
arrangement of modifiers - in what order I should put them if I want to apply several different effects
Project state:
This is definitely a beta thing at the moment. Some things just don’t work yet, the compiler is often extremely unhelpful, showing very cryptic error messages or showing them in a wrong place, and the reference documentation is incomplete. Autocomplete only works about half of the time. This will hopefully get better by September, although I suspect it won’t be completely perfect by then.
Also not every feature from the native frameworks that we might need is exposed in the new API, and that’s kind of by design - that’s why we have NSViewRepresentable and UIViewRepresentable. Hopefully more and more shared and platform-specific things will get added in future versions (and hopefully we won’t have to wait until June 2020 to see anything new).
Potential:
We’ll only know for sure once we start using SwiftUI in real, full size apps, but judging by what we’ve heard so far, the potential for saving us work, speeding up development and eliminating bugs is huge. I can’t wait…CocoaMac
WatchKit Adventure #2: Minimum Viable Complication
< Previously on WatchKit Adventure…
This post is the second (or technically third) part of my series about building a WatchKit app that shows current air pollution level on the watch face. If you haven’t seen the previous parts, you might want to at least take a look at the intro.
Last time we’ve talked mostly about the general architecture of a WatchKit app. So logically it would now make the most sense to start with the main part of a watch app, the main app UI. After all, this is the only part of the app that’s required - both notifications and complications are optional if you don’t need them. This is what people normally think of when they talk about “an app”.
However… the whole thing started with me wanting to see the level of air pollution right there on the watch face, as quickly as possible. One of the three main rules of watchOS design is that apps should be glanceable, which means that you should be able to glance at the watch and see the information you need in as short time as possible, ideally within a couple of seconds at most - and a complication lets you see this information much much faster than the main app UI accessible from the app launcher.
It was also mentioned during at least one presentation that unlike on iOS, here the main UI does not need to be the most commonly used part of your app, if notifications or a complication make more sense for your use case. It can very well be something that users only fall back to sometimes when they need to see more detailed information or perform some actions.
So, why don’t we skip the view controllers for now and just build a complication?
And that’s exactly what I’ve started with. I’ve built a simple “MVP” version of an app with just a complication (and just in 1-2 variants) during the Christmas break. It has no UI whatsoever, the main view is just an empty black box, the storyboard is unchanged from the template, and I haven’t written a single line of code that touches any WKInterface* object.
But this app with no UI already serves its purpose - I’ve been running and testing it since the end of December, and it already provides me with the information I wanted. Sure, it could let me choose the measuring station and the specific parameter (PM10, PM2.5, NO2 etc.), or use a more precise source of data, or show me a chart of the previous few hours. This would all be useful, but the only essential part is showing a single number on the watch face and updating it once an hour, and that already works:
Yeah, coding on Christmas - don’t judge me
It took me much longer to start writing this post than I planned, but not because of procrastination - I’ve just been testing the app in so many different combinations in order to learn how the SDK exactly works, what to expect and what I need to take into account when writing the app to cover all edge cases. There will be time to talk about this later, but for now let’s build this simplest possible version that just gets some JSON data from …CocoaWatchKit
WatchKit Adventure #1: The Big Picture
Update 03.07.2019: watchOS 6 has changed a lot of things that I’ve written about here, so I went through the post again and updated all parts that got out of date.
< Previously on WatchKit Adventure…
For some reason, after watching WWDC talks mentioning watchOS in the last few years, I had this image in my mind that almost every version changed everything in how apps are built. I remembered something about native and non-native apps, two different types of app schemes in Xcode, and some diagrams of pieces moving from one box to another, on more than one occasion. This all sounded confusing, and I think that’s one reason why I was discouraged from starting, because I imagined it would make it hard for me to catch up with all of that.
As it turned out, this wasn’t really true. Well, not until watchOS 6 at least 😉
In this first episode, I want to start with a bit of an overview of what pieces a watchOS app consists of, how they fit together and how it all changed since the first version. Like with my Dark Mode articles, what I’m trying to do here is collect the information I’ve found in docs like the App Programming Guide for watchOS, the official documentation site and in the WWDC videos I’ve watched, and organize it in a way that makes sense to me (and hopefully to others). I’ve found that very often related pieces of information are scattered through several talks, and it only starts making sense to me once I collect some notes while watching them and then rearrange everything, grouping things by topic, so that I see all information in the right context.
This got a bit long, but bear with me, I expect next episodes to be shorter and much more practical :) (*)
(*) Spoiler: they’re longer ¯\_(ツ)_/¯
The watchOS application
The first thing to note is that unlike macOS, iOS and tvOS, watchOS is (still) not a completely independent platform: the Watch relies to a larger or smaller degree on the paired iPhone. It can work independently for some periods of time without the phone, especially if it’s an LTE variant, but it cannot completely exist without one. You need an iPhone to set it up, to update the OS, or to change some of the settings through the “Watch” app on your iPhone.
Over the years, this relationship got more and more loose, as you’ll see in a moment - but the connection is still there, and it probably won’t disappear completely soon.
One important aspect of this, which as far as I know hasn’t changed so far, is that Watch app’s storage isn’t backed up at all to iCloud or local iTunes backup when you sync your phone. This means that you should not let it keep any precious information that can’t be recreated and isn’t synced anywhere. Anything that’s created on the Watch should be quickly synced at least to the companion iOS app (if there is any), and ideally straight to the cloud.
This close relationship between the Watch and the iPhone means that in a lot of cases your users might want to perform the same activity simultaneously …CocoaWatchKit
WatchKit Adventure #0: Intro
Ever since I saw the first Apple Watch announced on stage, I wanted to learn to write apps for it. I bought my first Watch half a year later, when they finally appeared in Europe, with that thought in mind. You can probably guess how that went…
I now have on my wrist my second Apple Watch (Series 1), bought two years ago after I smashed the screen in the first one. And to this day I haven’t written a single line of code for watchOS… This is actually one of many things that have been on my ToDo lists for literally years, that I often think about, but never actually find time to do. Procrastination is a terrible thing.
But I’m trying to fight it. So after going through a lot of docs and most of the WWDC talks about WatchKit more than once, it’s time to try it out in practice.
For a long time I’ve had an idea for a simple app in mind. I live in Kraków, a city that’s been kind of infamous in the recent years (maybe somewhat unfairly, because it’s a problem of whole Poland) for having a terrible smog during the colder months every year. A lot of people burn coal to heat their houses, often low quality coal or in low quality stoves, and some even burn literally garbage, with plastic and everything. And what makes things even worse is the unique geography of Kraków, which is located in a river valley surrounded by hills, which makes all polution slide down and stay inside, only pushed out periodically by stronger winds. This all results in pollution levels that in some Western European countries would trigger critical pollution level alarms on most of the winter days.
Due to a lot of campaigning by some activist groups, things are gradually improving, but slowly. For now, if you care about your health, or spend time outside e.g. jogging or commuting by bike, you need to have a filtering mask and know on which days to put it on.
You can imagine where this is going: it would be ideal to have a Watch app with a complication on the watch face that I could quickly glance on in the morning. That way, in literally a second - without the need to even open any app - I would know if the PM10 level today is e.g. 50 µg/m3 (officially at 100% the safety limit, but in Kraków considered “pretty good” in winter) or 150-200 µg/m3, which means I really need to put on the mask if I don’t want to feel slightly ill later.
There are of course many air quality apps available globally or made specifically for the Polish market (or even just for Kraków), but I’ve looked through them now and I could find only three that include watch apps, and none of them offers a complication. Also, I don’t fully trust those that aren’t made in Poland, because I don’t know how to read their data in the local context - like I mentioned, an “acceptable” level here could be considered “critical” elsewhere…
We have a pretty good local air monitoring system with several sensor stations from which you can easily download hourly data, so that would be enough. There’s also an independent system…CocoaWatchKit
New stuff from WWDC 2018
For the last 3 WWDC’s I’ve been collecting ordered lists of all new features and APIs added in the new releases of Apple’s OSes, either announced in the keynote or one of the talks, or in release notes, or just discovered by some API diff spelunkers :) I’m pretty late with that this year, because I spent some time instead on a couple of longer posts about notifications and Dark Mode, but here it is, just in time for the final launch and the September event.
In general, there seems to be noticeably less changes this year, which is good in a way - it should be easier for us to learn the new things and update our apps. For a moment it even looked like the “macOS SDK” section could be longer than the “iOS SDK” this time with all the Dark Mode changes, but iOS got a boost from the notification APIs and finally finished 3 lines ahead of macOS :)
If you want to learn more about any given topic, the best way is probably either to look it up in the shiny new Apple Developer Documentation (redesigned last year), or watch the recorded WWDC talk videos - either on Apple’s site, or using the great unofficial WWDC Mac app.
Previous editions are available here:
WWDC 2017
WWDC 2016
WWDC 2015
Quick links:
macOS 10.14 • iOS 12 • watchOS 5 • tvOS 12
Foundation & Core Frameworks • macOS 10.14 SDK • iOS 12 SDK • watchOS 5 SDK • tvOS 12 SDK
Web APIs • Developer Tools • Safari 12
macOS 10.14 Mojave
🗄️ https://www.apple.com/macos/mojave/
Dark Mode (more info: part1, part2)
8 accent colors instead of just blue/graphite
Desktop:
dynamic wallpapers
desktop stacks
Screenshots:
thumbnail sliding in in the corner like on iOS that opens an edit view
options HUD while screenshot is being taken (Cmd+Shift+5)
recording screencasts from inside the screenshot tool
new redesigned Mac App Store
new apps ported from iOS with Marzipan:
Home
News
Stocks
Voice Memos
Books:
renamed from iBooks to Books
Finder:
gallery view replacing Cover Flow
right sidebar shows more file metadata (e.g. for photos)
the set of fields shown can be configured per file type with the “Show Preview Options” context menu action (source)
quick actions on files in the right sidebar and Touch Bar
new actions can be created in Automator (“Quick Action” template, replaces older “Service”)
markup editing and video trimming inside Quicklook
iCloud Drive has now its own section in the folder sidebar (source)
FaceTime:
group calls - up to 32 people (delayed)
Mail:
emoji picker button
suggests a folder to move a message?
stationery feature removed
Safari:
favicons in tabs
prevents tracking through commenting systems and share buttons (loads on demand)
makes fingerprinting harder - lists only built-in fonts, no legacy browser plugins
iCloud Keychain:
can automatically create strong passwords for you when signing up
highlights duplicated passwords
Siri can be asked to find saved passwords
Continuity Camera - use your iPhone as an external camera to take a photo for the Mac
forms will auto-su…CocoaiPhone
Dark Side of the Mac: Updating Your App
(Part 1 is available here.)
Last week I posted an article here about how the “Dark Mode” in macOS 10.14 works behind the scenes and how such features as appearances, materials and vibrancy, which were present in macOS since at least 10.10, have been extended to work with the new visual style. This is the second part of that article - now that we have the theory behind us, let’s see how you can make your own app work with dark mode.
The first thing to remember is that dark mode is automatically enabled in apps built with the 10.14 SDK (which will be in beta until September, so it can’t be used for Mac App Store app releases yet). This means that:
Even if you use all the right APIs, your app will display as completely light on a dark Mojave desktop unless it’s recompiled on the new SDK - which makes sense, since otherwise most third party apps would look pretty ugly.
When you switch to the new SDK, the app will use dark mode on a dark desktop whether you like it or not, which might not be good if you haven’t updated it at all.
Apple has solved both of these problems with an Info.plist key named NSRequiresAquaSystemAppearance:
if it’s set to true, it disables the dark mode when the app is built on the new SDK, so you can buy some time this way to tweak everything in the app until it looks great on a dark desktop; Apple has emphasized that this should only be used temporarily :]
if it’s set to false, it enables the dark mode when the app is built on the current SDK - you can use this if you can’t or don’t want to switch to the new SDK yet, but want your app to not look out of place on a dark desktop
Interestingly, it seems you can also override this property through the NSUserDefaults system as a user, for any 1st or 3rd party app (at least if it doesn’t set it itself in its Info.plist?). This means you can make a system app “forget” how to use the dark mode:
And you can also force a third party app to try to work with the dark mode:
The former should usually work, the latter will depend on how much the app was following various good practices, which we’ll talk about later in this post. Be aware though that some apps might even crash when this user default is set!
If you’d like to instead force an app (that already supports dark mode) to always use it, even in light mode, there was a NSWindowDarkChocolate property before which did just that, but apparently it was removed in Beta 2. I’ve tried the alternative _NSSystemAppearanceOverride mentioned in that tweet and it seems to work for now - both with DarkAppearance, and to force a light appearance you can use a value of NSAppearanceNameAqua.
Note that everything about user defaults (not Info.plists) described above is an undocumented behavior and it can all stop working at any moment.
Debugging Dark Mode
There are also two new features in the Xcode 10 UI that can help you during testing:
when you open a Mac storyboard (or XIB, if you’re old school 😛), there is a new “View as” switcher av…CocoaMac
Dark Side of the Mac: Appearance & Materials
One of the most exciting announcements at this WWDC was the introduction of a long-awaited “dark mode” in macOS 10.14 Mojave, which lets you use a whole desktop with all the apps on it in a dark theme, instead of just the dock and the menu bar as before.
While I’m not nearly as excited about it from the user’s perspective as some others are 🙂 - I’m totally a “light side” Mac user, I’ve always used a light theme in TextMate, light theme in Xcode, white background in iTerm, and I sometimes have to use reader mode on websites with a dark background - I’m actually very curious about it as a developer. The reason is that it seems to require a lot of changes across apps to adapt them to the new appearance, or at least a lot of checking and testing, but it does so in a way that feels like “making things right” - not so much introducing complexity just for this reason, but rather enforcing some order and good practices that were earlier easy to forget about. As you’ll see, a lot of work might actually be about removing things.
As with the changes in notifications, I’ve set out to collect everything related to dark mode from the WWDC videos this year and organize all the information in a way which makes more sense to me (since in the talks these things are often mentioned in a slightly random order and topics are scattered through multiple sessions). This eventually grew into the longest article on this blog, so instead of deleting some sections, I’ve decided to split it into two parts. This first part will be a bit more theoretical about some underlying features and APIs that make the dark mode work or that are especially relevant now, and the second part will be about the things you need to think about while updating the app (and in the future).
I’ve learned a lot about AppKit while writing this, and I’ve managed to clear up a lot of things which I didn’t fully understand before, so I hope this will help someone else too.
(Part 2 is available here.)
NSAppearance
The funny thing is that a large part of what makes Dark Mode work and what was explained in the WWDC talks this year was available since… 2014, when OSX Yosemite (10.10) was introduced. A lot of it sounded kind of familiar as I was listening to it, so I started digging in ASCIIwwdc, and I’ve found three videos from WWDC 2014 that were talking about the exact same things (links at the end if you’re interested). Interestingly, there was barely any mention of all that between then and now, so you have to go all the way back to WWDC 2014.
As with a lot of things before - like AutoLayout or size classes - Apple has introduced some APIs back then that were at first ignored by a lot of people, which have later turned out to be really important after some hardware or software updates made years later. And again, looking back now at the 2014 talks, it seems kind of obvious in retrospect that these APIs would eventually lead to a full dark mode.
The base class for the appearance system is the NSAp…CocoaMac
What's new in notifications in iOS 12
One of the things that caught my attention in the WWDC videos I watched last week were the improvements in the notification system, meant to on one hand give more control over notifications to the users and make them a bit less overwhelming, and on the other hand make them more useful by allowing them to be more interactive.
I’ve tried to sum up here all the changes related to notifications that I’ve found - there’s nothing here that you can’t find by yourself in the videos, but I figured it’s worth putting it all in one place in a concise form.
Most of the below applies to both iOS 12 and watchOS 5.
Notification grouping
One feature that users will probably notice very quickly is that notifications are now grouped on the lock screen and in the notification center. This happens automatically, but you (and your users) will be able to customize it. The user can expand and collapse the whole group to see and interact with specific notifications in it, and they can clear specific notifications or the whole group.
By default, notifications will be grouped by app - which means all notifications from your app will be packed into one stack, showing only the newest one (called “leading” in the videos) in detail, with a small subtitle like “5 more notifications” below. This can make sense for a lot of apps, if they don’t have any concept of threads/conversations or any other way of dividing notifications into distinct groups. But if your app does, you can customize this.
To override the default grouping, you can assign specific notifications their “thread IDs”. You might already be doing this, since it’s not a new feature - this was added last year in order to let you group notifications with hidden content on a locked device’s lock screen. The whole grouping API added now is really just an extension of that system from iOS 11, so if you’ve implemented hidden previews, this works in a very similar way.
So if you do assign a thread ID, all notifications for a given thread will be grouped together, but separately from other threads. Some examples of how this might be used showed in the video:
in the Messages app, messages are grouped by conversation
in Mail they’re grouped by account by default, then conversations with VIP contacts are grouped separately by person, and threads manually followed are grouped by thread
Calendar app groups most notifications in one group (thread ID = nil), except important notifications about events starting soon that are separate from the rest
General tips mentioned there included:
Separate important, actionable notifications from informative updates
Create groups for meaningful, personal communication
Respect the user’s priorities and organization
Also, take into account that the user can override this to still put all your notifications into one group, or to not group them at all. And you probably shouldn’t try to abuse this system to put every notification in a new thread just because…
If the user opens a No…CocoaiPhone
Changes to location tracking in iOS 11
Apart from a whole bunch of new frameworks (see the whole list here), iOS 11 also makes some major changes to existing APIs. One of the affected areas is location tracking. If your app only uses location while the app is in the foreground, as most apps do, you might not have to change anything at all; however, if it’s one of those apps that continuously track user’s location throughout the day, you should probably book some time this summer for making some changes in how you do the tracking and testing possible usage scenarios.
This post is mostly based on the “What’s New in Location Technologies” talk from WWDC, so if this topic is relevant to you then you should definitely watch the whole talk.
How it worked in iOS 10
First, a bit of introduction for those not familiar with location tracking APIs - feel free to skip this section if you want.
In iOS 10 and earlier, apps can request access to user’s location in two ways, depending on how they plan to access and use it:
“While Using” access
Most apps only need to access user’s location while the user has the app in the foreground and is actively using it. This could be continuous access for displaying user’s position on a map, which is being updated as they move (MKMapView.showsUserLocation), or one-time access at specific points in time, e.g. when running a search on the server to return nearby restaurants or hotels, or current weather conditions in user’s area.
To access location this way, you need to provide an NSLocationWhenInUseUsageDescription key in your plist file, describing why you need location access, and ask for “While Using” access inside the app by calling locationManager.requestWhenInUseAuthorization().
This is what the user will see when you call requestWhenInUseAuthorization():
There’s also a class of apps that need to track location while the app is in the background, but still used in a way that can be described as “being actively used”. This includes mostly fitness apps that track user’s movement during a workout, and navigation apps. In those cases, the user won’t be looking at the screen all the time (most likely they’ll have the device locked most of the time), but they will still be doing some kind of activity related to what the app is tracking.
If you use location this way, iOS will display a very conspicuous blue bar at the top of the screen when your app is in the background, to remind the user that the tracking is still in progress:
In all above scenarios, the app has no reason to access user’s location while they aren’t actively using the app - it would only unnecessarily drain the device’s battery, so the “While Using” access level is completely sufficient.
“Always” access
The second way is to ask the user for access to their location 24/7, regardless of what they’re doing at the moment. Very few apps should really need this; this might include apps that suggest the user new places to see as they move around, e.g. while they’re visiting a new city, or a…CocoaiPhone
New stuff from WWDC 2017
It’s that time of the year again - if you’re like me, you’ve probably spent a lot of time in the last few weeks following everything that’s been announced at WWDC, digging into release notes, watching WWDC talks and playing with some cool new stuff. And as usually, the amount of new things to process is pretty overwhelming.
So like in the last two years, I’ve prepared a nicely organized list for you of all the things I could find from various sources: all the user-facing features in macOS/iOS/watchOS/tvOS, and all new frameworks, APIs and improvements in their respective SDKs and Apple’s developer tools.
To get more info about any specific thing, follow the links above the sections to Apple’s developer site and the “What’s New” documentation, download the release notes from developer.apple.com, and of course use the freshly redesigned unofficial WWDC Mac app to watch the talks that you’re interested in.
If you want to catch up on last year’s notes (e.g. to see what you can use if you drop iOS 9 support in your app), check out these posts:
WWDC 2016
WWDC 2015
Quick links:
macOS 10.13 • iOS 11 • watchOS 4 • tvOS 11
Foundation & Core Frameworks • macOS 10.13 SDK • iOS 11 SDK • watchOS 4 SDK • tvOS 11 SDK
Developer Tools • Safari 11 • Other
macOS 10.13 High Sierra
🗄️ https://www.apple.com/macos/high-sierra/
Mail:
smart highlight of important emails
split view for compose window
uses less disk space
Messages: syncs conversations through iCloud between iOS/macOS (end-to-end encrypted)
Notes:
pinning notes
support for tables
Photos:
persistent sidebar
shows all imports chronologically
improved face recognition
synchronizes people across devices
curves and selective color edit tools
more partners for printing photos
more available topics for memories
photos can be edited in 3rd party apps and are saved back into Photos app
playing animated GIFs
live photo effects
Safari:
video autoplay blocking
intelligent tracking prevention
per-site settings (e.g. enabling autoplay or disabling content blockers on some sites)
automatic reader mode
Spotlight can find more kinds of web results, e.g. flight info, and can return multiple results from Wikipedia
smoother, more natural sounding Siri voice
window server (Mission Control etc.) is built on top of Metal 2
APFS is the new default filesystem for new installations
H.265 (HEVC) video support, with hardware acceleration in newest Macs
accessibility:
new on-screen accessibility keyboard
Type to Siri (disables voice interface)
voiceover descriptions of images will now include automatic description of the image contents and any detected text
iOS 11
🗄️ https://www.apple.com/ios/ios-11/
redesigned control center
single page, animations
more controls shown with 3D Touch
some areas can be customized
allows you to toggle e.g. cellular data, hotspot, AirDrop
new design for app switcher:
new animation
no longer shows the home screen as the first app
older notifications accessible from the lock screen…CocoaiPhone
New stuff from WWDC 2016
Following the tradition from last year, here’s my complete list of all interesting features and updates I could find in Apple’s OSes, SDKs and developer tools that were announced at this year’s WWDC. This is based on the keynotes, the “What’s New In …” presentations and some others, Apple’s release notes, and blog posts and tweets that I came across in the last few weeks.
If for some reason you haven’t watched the talks yet, I really recommend watching at least the “State of the Union” and the “What’s New In” intros for the platforms you’re interested in. The unofficial WWDC Mac app is great way to download the videos and keep track of what you’ve already watched.
If you’re interested, here are my WWDC 2015 notes (might be useful if you’re planning to drop support for iOS 8 now and start using some iOS 9 APIs).
(This was originally posted on Gist at https://gist.github.com/mackuba/e8fb4219c7ef611f47cdb66b93986d85.)
Quick links:
macOS 10.12 • iOS 10 • watchOS 3 • tvOS 10
Foundation & Core Frameworks • macOS 10.12 SDK • iOS 10 SDK • watchOS 3 SDK • tvOS 10 SDK
Developer Tools • Other
OSX → macOS 10.12 Sierra
🗄️ http://www.apple.com/macos/sierra/
includes Siri
launch from dock, menu bar or with a keyboard shortcut
results can be pinned to the “Today” sidebar
some returned results like images can be drag&dropped to another app
any app with multiple windows can now group them into tabs in one window like in Safari or Finder
option in preferences to automatically use tabs: only in full screen (default) / always / never
new design for notification center / today sidebar
Universal Clipboard - copy/paste between Mac and iOS devices
Desktop/Documents folders can be automatically synced with iCloud Drive (?)
Auto Unlock - unlock the computer automatically with your Apple Watch
Picture-in-picture for video like on iOS
when dragging a window next to another, it will snap to the other window
all items in the menu bar can be reordered, removed (if the app allows it) and also navigated with keyboard
Safari:
blocks plugins like Flash, Java, Silverlight with click-to-run overlays, and doesn’t tell sites that they’re installed
makes Apple Pay available to websites - payments are confirmed with an iPhone or Apple Watch (a site can apparently even check if an iPhone is available nearby to pay?)
can now restore multiple previously closed tabs with Shift-Cmd-T like Chrome
updated Messages and Photos apps and Apple Music in iTunes with features matching iOS 10
a set of new features for reclaiming free space:
rarely used files can be moved to iCloud
automatic cleanup of files that aren’t needed anymore (e.g. caches, logs, backups)
automatic cleanup of files that have been in Trash for 30 days
new graphical tool for configuring these features
Gatekeeper changes:
option to allow any (non-signed) software is removed (right-click + Open still works)
Gatekeeper Path Randomization - newly downloaded non-MAS apps will be run sandboxed inside a read-only volu…CocoaiPhone
New stuff from WWDC 2015
Here’s my own list of the interesting stuff announced during this year’s WWDC, collected from the keynotes, various Apple docs, blog posts and tweets.
If you’re planning to watch the videos, I really recommend this Mac app that helps you download and watch them: https://wwdc.io.
(This was originally posted on Gist at https://gist.github.com/mackuba/15994186a4f9d7da3137.)
OS X 10.11 El Capitan
🗄️ http://www.apple.com/osx/elcapitan-preview/
split view - two apps side by side on full screen
improved Mission Control
shaking the mouse highlights the cursor
smarter Spotlight (Siri-like results, natural language queries, resizable window)
Mail: tabbed compose window as a popup in full screen mode; autosuggests new contacts and events; swipe gestures
Notes: updated UI, supports checklists and embedded media, syncs through iCloud, attachment browser
Photos: sorting albums by date
Safari: pinned sites, detect and mute audio in tabs
Maps: public transit
significant performance improvements, mostly thanks to the Metal framework
new beach ball cursor
new system font (San Francisco)
Safari developer tools: responsive design mode
System Integrity Protection - limited some privileges of admin accounts (can’t modify system files or access system processes) - can be disabled with a special utility
redesigned disk utility, new color picker, option to autohide menu bar
iOS 9
🗄️ https://www.apple.com/ios/ios9-preview/
more intelligent Siri
proactive suggestions in various places
more intelligent search feature, extensible by apps
iPad multitasking - slideover, split view, Picture in Picture
Notes: supports checklists and embedded media, sketch drawing, syncs through iCloud
Passbook renamed to Wallet, can hold reward cards etc.
Maps: public transit, finding places nearby
News app
iCloud Drive app that shows all contents of your iCloud drive
“Move to iOS” app (in the App Store) for migrating from Android
iPad keyboard - copy/paste buttons, dragging on the keyboard makes it select text
iPad external keyboard - app switching
new app switcher
lowercase keyboard
low power mode
smaller download size for OS updates and less free space required to install
passcodes can be 6 digits long
to log in on a new device, you need to enter a verification code shown on one of your existing devices
full right to left support - in RTL mode, everything is right to left - system controls, layout, gestures, navigation, tab bars etc.
optimized UI, up to 1h more of battery usage
notifications don’t light up the screen if the iPhone is lying face down
popovers now drop a slight shadow around them on the underlying view
“share” option added to the popover shown when selecting text
watchOS 2
🗄️ https://www.apple.com/watchos-2/
new watch faces (photo, album, timelapse)
time travel feature - shows events and predicted status of various things (e.g. weather) in the future or in the past if you’ve missed something
night stand mode - landscape display, buttons act as “snooze” and “off”
pub…CocoaiPhone
Testing Retina images on an older Mac
Update 7.12.2020: Added info at the bottom about a UserDefaults setting you can use instead.
If you build iOS apps, you’re used to providing all icons and other images in @1x and @2x versions for older and Retina screens respectively (or rather @2x and @3x now). And it’s pretty easy to test if all those versions work or not, by starting the right iOS simulator and looking at it scaled to 100%.
If you work on Mac apps, you should also include @2x images for Retina Macs now; but if you’re like me, you might have treated that so far as something not urgent that can be done later…
When you do get around to that, if you don’t have any Retina Mac yet, you’ll quickly notice a problem: how do you test your app on a Retina screen? There’s no OSX simulator in Xcode, after all.
Fear not, turns out there is a tool that lets you turn your Mac into a Retina MacBook simulator, it’s just pretty well hidden.
First, go to the Downloads page on developer.apple.com and find the latest “Graphics Tools for Xcode” package on the list (you might find many versions, but the latest should be on the first or second page - right now it’s the Xcode 6.1 version from Oct 2014). This includes various thingies that were distributed with Xcode before and could be found in /Developer, but now were removed from the main bundle.
Open the DMG and run the Quartz Debug tool (you don’t need to extract it anywhere, you only need to do this once). It will show you a small HUD window, but ignore it and instead open the “UI Resolution” panel that you can find in the Window menu:
See that checkbox? Yeah, you need to check it. And unfortunately you’ll need to either log out and back in or restart your computer for this to work. You can close Quartz Debug and you can even delete the DMG (though some of the other tools there might be useful too, e.g. Icon Composer).
When you’re back, open the standard Displays panel in the System Preferences, and you should see at least one additional resolution on the list - this will be a special @2x mode that runs at half your normal resolution:
When you select that, your desktop will look a bit funny and you’ll have much less space, but you’ll be able to see which of the icons and controls adapt to a Retina screen properly. This is the result of doing this on my iMac (it turned the standard 1920×1080 resolution into 960×540@2x):
It does work on smaller screens too, but the effective resolution gets really small so it’s not as comfortable; here’s a screenshot from my MacBook Air at 720×450@2x (as you can see, Xcode is not terribly usable at such resolution :).
BTW, prepare to feel confused for a few minutes after you switch back - the cursor movement and animation will feel slower and so on :) All the windows will also stay resized to much smaller dimensions, and iPhoto might start complaining about having to generate @2x thumbnails (it’s probably better to not have it running while you’re doing this).
Update 7.12.2020: Turns out that there is al…CocoaMac
Accessing user location data in iOS 8
In iOS 8 Apple made some changes to how apps are supposed to request access to location data. If you use CLLocationManager and you don’t make any changes for iOS 8 compatibility, your app might stop receiving location data at all.
Permission types
The biggest change is that apps can now ask to get location data either “Always” or “While Using”:
The “Always” permission is used for the less precise but more battery-friendly location monitoring modes, like the “significant changes” API or region monitoring. “Always” means that you want access to the location data 24/7, so obviously you can’t use the standard API that returns precise GPS data every second, at least not all the time, or you’d drain any iPhone in a couple of hours.
Few apps should actually need this permission, and I think the main point of this change was to discourage apps from spying on you permanently unless they have a really good reason. One app for which this does make sense is Swarm/Foursquare, which wants to provide users relevant info while they move around the city. Also any apps that detect beacons will require this, or apps that execute some reminders or actions when you come to a different place (e.g. todo apps).
The “While Using” permission is what at least 90% of apps should use instead. “Using” means that you either only use the location data while the app is actually on the screen and the user is interacting with it, or the app is in the background, but it’s doing something important for the user for which the location data is crucial (think: navigation or some kind of fitness activity). In the latter case (e.g. RunKeeper running in the background) iOS shows an extremely conspicuous blue bar at the top of the screen to make it clear that the location data is being actively accessed:
If you only use location data while the user is interacting with the app in the foreground, then it’s recommended that you stop monitoring location immediately when the app starts hiding into the background. If you don’t do this quickly enough, the user will see this blue bar for a couple of seconds after closing your app (you can see this e.g. in the Google Maps app).
Note: it’s perfectly acceptable for apps to include both permission options - in fact I’d say that it should be considered a good practice for apps that request the “Always” permission to also fall back to “While Using”. Again, a good example is Foursquare. By default it asks for “Always”, so that it can show you notifications when you come near interesting places. However, if the user does not want to be tracked by Foursquare all the time, but they still want to be able to use location data in the app (in order to search for nice cafes or restaurants nearby or to check in to them), they can give Foursquare the “While Using” permission and only let it access their location while the app is active. A nice app should respect that decision and not present the user with an “all or nothing” choice.
At the moment most app…CocoaiPhone