Tag: iphone
メモ：iPhoneを買い換える際の注意リスト
減ってきてはいるけどもめんどくさい。対応が必要なアプリの自動特定ぐらい欲しいな。
New Bluetooth hearing aids
Back in autumn 2022, following a decline in my hearing, I started wearing hearing aids. Almost four years on, and following a new hearing test, I've got new, upgraded hearing aids - and these ones have Bluetooth. Bluetooth hearing aids have been around for some time now, but were normally only available if you paid...
Midlife iPhone overhaul
Last month marked three years since I bought my iPhone 13 Mini. Unfortunately, it was starting to show its age a little - the battery was not holding charge very well, and the charger port was being awkward, which exacerbated the charging issue. I quite like the size of the iPhone 13 Mini, and I'm...
iPhone photo and video editing apps
Seeing how I cannot seem to use an actual camera to take pictures, I am doing my annual exercise of taking stock in the photography apps I use on my iPhone. When upgrading to the 17 Pro iPhone recently, I got the 1TB version, which means I have more room to store photos and videos taken at higher resolutions. For years I used Lightroom by Adobe. But ever since Adobe’s attempt to charge me to cancel a subscription, I have vowed to never use any of their services again. I also did not like having ...
My Opinion on the iPhone Air
In the September Apple event, the iPhone Air was announced along with the iPhone 17, 17 Pro, and 17 Pro Max. I've grown fond of the iPhone Air as soon as I saw it, because it was a sign that innovation at Apple wasn't dead... yet. After the event, everyone jumped on their platforms to express their (biased) opinions, but one of the opinions that I have adopted is, who is the iPhone Air for?
Neues aus dem Innovations-Labor von Apple!
Eine humorvolle Betrachtung der neuesten Innovation von Apple: die iPhone-Socke.
Going Light-ish
Thoughts on the confusing genius of the Light Phone 3.
The Finance Team Lost One
For years, many of Apple’s most consumer-unfriendly decisions have felt like an extension of a revenue-optimization strategy at constant risk of backfiring. Thanks to a bracing legal decision, now it has.
Tethered
On the freedom that cellular modems gave to consumers—and how mobile companies tried to claw it back during the iPhone era.
iPhone-Hack: Fotos ohne automatische Nachbearbeitung aufnehmen
So ziemlich jedes Smartphone bearbeitet Fotos direkt nach der Aufnahme automatisch nach, um die Schwächen der kleinen Kamerasensoren auszugleichen. Kontrast und Sättigung werden angehoben, es wird…
No Stone Unturned
A rock traveled in my camera bag, and was photographed time and time again.
No Stone Unturned
A rock traveled in my camera bag, and was photographed time and time again.
VSCO
A collection of iPhone photos from California, Hawaii, and India, edited with VSCO
VSCO
A collection of iPhone photos from California, Hawaii, and India, edited with VSCO
The Web App Switcheroo
In its quest to do as little as possible to comply with the EU’s Digital Markets Act, Apple randomly kneecaps web apps. Also: Am I sending this newsletter to fake people?
Momente (10)
„Momente“ sind mit dem iPhone fotografiert und bearbeitet. Verwendet wurden die Standard-iOS-Kamera-App, Focos, Camera M und Lightroom.
Counterfeit Computing
Discussing the piratical efforts to rip people off by counterfeiting computer hardware. It’s been happening for more than 40 years.
Bubble Busters
The recent security drama caused by an iMessage workaround on Android shouldn’t minimize a simple fact: This is Apple’s fault.
Momente (9)
„Momente“ sind mit dem iPhone fotografiert und bearbeitet. Verwendet wurde die Standard-iOS-Kamera-App.
Fehler -7003 bei der HomePod-Einrichtung
Sollten Sie bei der Konfiguration eines neuen HomePods auf den oben gezeigten Fehler stoßen, liegt es wahrscheinlich daran, dass Sie in den iCloud-Einstellungen den erweiterten Datenschutz aktiviert…
Momente (7)
„Momente“ sind mit dem iPhone fotografiert und bearbeitet. Verwendet wurden neben der Standard-iOS-Kamera unter anderem diese Apps: Halide, Spectre, Focos, SKRWT, Darkroom und Snapseed.
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…
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…
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…
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…
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).
The Internet Of Trash
We may have made a horrible mistake by unnecessarily making our consumer electronics devices smart—and removing generations of future use in the process.
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…
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…
iOS 13-Tipps
Außer den offensichtlichen Neuerungen in iOS 13 gibt es auch ein paar, die nicht sofort auffallen. Bei einigen fragt man sich, warum sie nicht schon viel früher Einzug gehalten haben … Safari…
Smartphones, Except Landlocked
Before the smartphone fit in your pocket, it sat on your desk—and sometimes, it was even called an iPhone. Let’s check out a few landline smartphones.
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 …
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 …
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…
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…