Tag: iphone
iTunesの購入済みの曲がミュージックアプリに見つからなかった件
iTunesとミュージックアプリの同期についての解決策
LinkTipp: The Apple Charging Situation
Hätten wir das auch geklärt.
メモ：mineoでのSIM→eSIM切替
何故できたか全く分からない。
メモ：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.
Bicicleta Ergométrica Bluetooth + Apple Watch
Nesse sábado (12), chegou minha bicicleta ergométrica Bluetooth. Quando minha esposa falou que queria uma, estávamos procurando algo barato, de 600 reais (+100~200 frete), mas lembrei de procurar algo um pouco mais inteligente, para que pudesse conectá-la a algum app e ter dados do exercício. Acabei achando uma que foi 1.600 (Frete incluso). Coisas tech me motivam, fazer o quê ¯_(ツ)_/¯ . Primeiros testes A bike chegaria na segunda, mas apareceu mais cedo. Montei ela e comecei a testar. Eu queria, inicialmente, usar aplicativos como o Zwift, onde há um mundo virtual que simula que você está na estrada. Acabei escolhendo […]
Going Light-ish
Thoughts on the confusing genius of the Light Phone 3.
not boring camera
the most fun i have ever had with a camera app
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.
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…