Siri Remote, Gruber's Review

Sunday, May 23, 2021

Three generations of Apple TV remotes, side-by-side.

I wanted to take a similar shot but my aluminium remote was lost. Read the Gruber’s review, it’s good. Here are some quotes which cracked me up.

I never liked that black Siri Remote, but over the years — six! — that I’ve been using it, I’ve grown to truly resent it.

It’s black and has no backlighting, which makes it harder to see in the dark. I believe some people like to watch movies in dark rooms.

This review made me think, why we need a dedicated play/pause button at all? Apple is learning from past mistakes and reusing things that worked. The plastic version (not in the picture) had the play/pause button in the middle. The current remote still can be used this way, pressing the middle button pauses playback. Perhaps the idea behind the dedicated control is to be able to pause music playback while you are in some other app or home screen.

Version Numbers

Saturday, May 22, 2021

OmniFocus 4 for iOS is coming out soon. I like that OmniGroup only incrementing the first number when there’s a real visible change. In this case, the app was rewritten from scratch with SwiftUI. I started using OmniFocus 1 when it was Mac only, it was the first time I have invested my own money in software. I didn’t have a credit card so I had to ask my friend to pay for the license key in exchange for cash.

There’s been 4 major OmniFocus releases, each with a big rewrite. This way version number plays a part in marketing, it’s part of the application, visible to the user. In a way, it belongs to a user. You feel like you own a particular version like you would own a particular car model. Clear version divide makes a choice to jump into the next version more conscious, meaningful, and fun. It also serves great in marketing. This is not the only approach to how developers name their applications but this approach I find most useful and tasteful. I like the clear divide between versions, you can see how a product is evolving. The major release usually takes years of development and it’s a little celebration for users and developers.

Siri Remote

Saturday, May 22, 2021

We also have received new Siri Remote last Friday to use with my existing Apple TV 4K. We spend one night using it and here’s my first impressions.

  • There’s no ergonomic issues, top from bottom can be distinguished easy by touch or look
  • A bit heavier and larger body, easier to grip
  • A bit sharp but not as sharp as the previous aluminium design
  • Siri button is on a side, helps in the dark
  • I needed to look at the surface glyphs to find pause button, this should get better with training because the back button has different surface shape, so you can find it and then go one row below, no need to look
  • There’s lightning cable in the box
  • Using the power button to turn off TV is great, and apparently there’s protection from accidental input as tvOS instructed me to hold it and only then the TV went off

At first I have attempted to read the manual which has very tiny print, and the room was dark. Still I glanced through first 2 pages and have not found any information about pairing. Then I just pressed a button, don’t remember which one and a popup window appeared on my TV with a tip to hold my remote near the Apple TV box in order to finish pairing. I did just that and it paired successfully.

I am still unable to decide should I use the click only mode which is disabled by default or should I use both click and touch. Initially my motivation is to disable the touch completely as I am so sick of accidental or imprecise input. However because this remote has new navigation buttons which can be used while the touch is enabled I will give it a shot and will update this post in couple of weeks. My main idea is to use the buttons for all UI navigation except video scrubbing and my main fear that I will trigger unwanted gestures when navigating.

Mixing Music and Podcasts

Wednesday, May 5, 2021

I see some popular music players like Spotify and Yandex Music integrating podcasts feature. I think it’s a bad idea for you as a listener. It might be financially beneficial for those big companies which are getting more of your attention in their apps, but you are better off on your own using specialized podcast players.

If you getting your podcasts in Spotify, unless you like the convenience of having music and podcasts in the same place, I guarantee you that any dedicated podcasting app like Overcast or Apple Podcasts would be a much better experience. AFAIK Spotify still doesn’t offer show notes and chapters — a very basic feature any other podcast player has to have. Spotify doesn’t care about details, they are too large to care about nerdy stuff. I am using Overcast since its launch because it has great privacy, robust offline-based search, industry best sounding algorithm for speeding up voice, and unique EQ mode – Voice Boost. If you see a podcast you want to listen to, search in Overcast or any other podcasting app. It will save you time and convenience later.

Objective-C

Tuesday, January 26, 2021

This post is dedicated to Dr. Brad Cox passing. It feels special when writing in Objective-C, the language which wants you to be as expressive as possible with its long method names, no performance compromises, and opinionated of how code should be structured. Thank you, Dr. Brad, for creating this language, unlike the others.

I have published my first app during the summer of 2014. Although the app itself is not useful for anyone except me, I still remember writing it. 123 Trim still on the store, and the process of writing it was fun, it felt special. At the time my background was in Java and JavaScript and Objective-C took some time to get used to, and string manipulations required more low-level code than my first language Java. I had a goal to make an app that can scale for different screen sizes and integrated with Safari. The app was simple enough so I can learn how to make apps. It was a fruitful adventure as I still enjoy writing in Objective-C to make a living and support my family.

The Mighty mini

Wednesday, October 14, 2020

Happy to see the iPhone 12 mini. If I would need a new iPhone today, I would go with the mini for sure. Having a better grip and shutter resistance is great, for me, it’s a breakthrough moment. I used to handle around an iPhone without a case, until a slippery peace of a soap 6. It would be great to have a caseless iPhone again with a strong grip and superior shatter resistance. Let’s wait for the eventual drop tests, remaining cautiously optimistic.

HomePod mini looks attractive, however, I am eager to find out more. I am sure it would blow out of the water the Google Home mini and the Amazon Echo Dot, but it might be too far from the original HomePod sound. I’m not sure how could Apple sound engineers achieve good highs with the HomePod mini speaker pointing downwards. What I really would like to see, is a second-generation HomePod, featuring all mini improvements, preferably with a lower price tag. Or, even better, a soundbar design with integrated Apple TV, like suggested by Jason on the Upgrade podcast.

Thanks to the MacStories for inspiring me with a title.

The App Store and Apple Pay

Tuesday, October 6, 2020

I know it seems obvious, but for a long time, you couldn’t choose Apple Pay, Apple’s own payment system, when setting up your Apple ID. I needed to update my card yesterday and have noticed the new option. I am attaching the screenshot, have you noticed the Apple Pay icon? It used to say “App Store”.

App Store screenshot showing the Florence game confirm with Touch ID payment sheet, the price is £2.99

This could bring new possibilities:

  • User can provide payment details only once, configure default, and choose a different card for each purchase.
  • Hopefully, if your app supports In-App Purchase, your customers now can pay with Apple Pay. Before that, Apple Pay was only allowed for physical goods, and required complex setup. I think 30% cut remains, but it potentially can allow Apple to switch to a 0% cut and just have much smaller commission they get from banks when you use Apple Pay.
  • User can use Wallet app settings to set a default card, instead of iOS payment settings.

Putting simply, if you can use Apple Pay to pay for your commute, buy a loaf of bread, or any web purchase, you now also can use the same technology when buying software on the App Store, wonderful.

Running iOS 13.7, UK App Store. I don’t see this on the Mac.

Update, October 8

I was billed for my iCloud Storage and the payment went through my card as usual. When I tried to remove this card from Apple ID payment settings, iOS told me I have to have at least one payment method available, despite that I have a second Apple Pay option configured in the list of payment methods. I am not sure is because I am a family organiser, but, most likely, you still have to have card details entered into your Apple ID. Apple Pay won’t be used for iCloud storage billing, and, possibly, subscriptions.

I have changed the post tile from “App Store now Supports Apple Pay” to the new one and changed “This brings new possibilities:” to “This could bring new possibilities:”.

On SwiftUI

Monday, August 10, 2020

SwiftUI is the future of app development. For the first time, there’s a unified way to write powerful applications for all Apple platforms.

There are 3 revolutions in personal computing technology.

  1. Mac and GUI.
  2. The open web.
  3. iPhone.

Each of these shifts was possible with a bunch of new technologies. I have a sense that SwiftUI can be one of those building blocks in the next step, democratising technology and opening new ways developers can build their applications. The reason I see its significance is that it combines the strength of native development and convenience of the web, it builds upon technologies of the past. In the same way, an open web wouldn’t be possible without a computer in each household.

It might be limited to the Apple world (fine with me), nevertheless, if SwiftUI proves itself as a success, it will be used to develop for the new platform, possibly AR/VR. The rest of the industry will follow in adopting a declarative way of programming user interfaces. I can not afford to miss this new revolution, I am very much committed to SwiftUI at this point.

Should Apple allow iOS apps outside the App Store?

Monday, June 22, 2020

Yesterday Brent Simmons wrote The App Store Doesn’t Make Apps Safe. Brent is a very well-known and talented Mac and iOS developer, author of excellent RSS reader NetNewsWire. I agree with his argument, Apple could allow iOS users to download apps from the web without compromising security. However, security is not the only concern here.

Update management is the biggest concern for me. I love how the App Store manages updates in a single place. Apps generally do not nag you to update, you can see all release notes and update quickly. You can manage auto-updating with a single switch. There are other pro-App Store arguments like, App Thinning, license management, Restoring Purchased Products, Family Sharing1, App Store reviews, and lack of third-party payments.

Mac is an excellent example of a system which allows apps from both places. I don’t like this duality. I am not comfortable making decisions about where to buy an app. The problem is that half of the apps available on the Mac App Store and another half, usually the most popular apps, on the web. In the event Apple allowing web installs, there will be an exodus of biblical proportions with the biggest apps leaving first to have more control, custom analytics, release automation, and to avoid App Store reviews. If we allow apps from the web now, it would be hard to go back.

  1. Many, if not all, Mac apps only allow you to use one license per person. This is not enforced in any way, but it feels wrong sharing your license with family members. 

Why HEY CEO is Wrong and Apple is Right

Sunday, June 21, 2020

Let’s just go through HEY CEO’s take on Apple’s App Store payment policies.

It’s about the absence of choice.

HEY customers have less choice now, they only can subscribe through the web.

It prevents us from providing exceptional customer service when someone who uses our product needs help.

You should not be forced to contact customer service for a cancellation or a refund. App Store allows you to do it in a couple of seconds.

When someone signs up for your product in the App Store, they aren’t technically your customer anymore - they are essentially Apple’s customer.

No, they still your customer, HEY. If you use Square for the payments on the web, your customers don’t become Square customers. Square just handles payments, as App Store does.

We provide hardship exceptions for all sorts of reasons. We discount our software for teachers. We provide free versions for first responders.

These people have to find a time to contact HEY and be dependant on the competency of HEY employees. Why not allow your product to be used for free in a limited way? Or offer discounts for everyone, which is possible with In-App Purchase (IAP) for new and existing subscribers.

Let’s say someone signs up for HEY on an iPhone, pays with Apple’s IAP system, and then decides to switch to an Android phone. Billing is entirely messed up now. They can’t update their credit card through the HEY app on Android because their billing info is stored with Apple. And we can’t help them.

IAP allows Server-to-Server Notifications. If your product available elsewhere, you could verify subscription status through Apple, and offer your customer an option to subscribe through the website, start billing them as soon as IAP subscription expires. I don’t see why HEY can’t do that. It is possible to have several payment methods on a single account. It’s not difficult to unsubscribe from IAP subscription if users decide to switch from iPhone, and this subscription would remain active even when auto-renewal is cancelled.

in app purchases are one of the most hostile customer experiences I’ve seen. Sure, the purchase part is relatively easy (most modern purchase flows are these days), but that’s where Apple stops

IAP is superior in speed, security, and privacy to any modern payment flow. No HEY, it doesn’t stops after the purchase is complete. IAP handles subscription management, refunds, renewals, Billing Grace Period, Push Notifications, and offers for retaining and attracting new customers.

Update: HEY was approved

As of Jun 22, HEY team adding a free version and update was approved. This proves that strict App Store rules, although sometimes vague and not fairly enforced, contribute to positive changes and superior user experiences than web or Android.

HEY App Controversy

Saturday, June 20, 2020

Why Apple doesn’t allow App Store developers to bill through their own systems? The most popular answer is that Apple wants to force them to pay a 30% (15% after 1 year) subscription cut. If that’s the only reason, Apple would ease this rule already. Apple hates the negative press, and this would help with Antitrust action. It is hard for Apple to hold its ground on this. But they not going to change their mind. At least, I hope, they won’t.

I think Apple shouldn’t change this rule. Developers can do this extra work and take this hit for their customer benefit. It sucks to download an app and realise that you can’t use it until you create an account, it sucks even more if you have to create an account and pay a subscription. You should be able to try the product first, and you shouldn’t be forced to give up on your privacy. The fact that developers can’t even add a link to a web payment is annoying, but it works, it’s an effective measure to force developers to add In-App Purchase (IAP), and this is great for Apple customers who now have an easy and quick way to pay.

This rule was created for a good reason — to provide the best user experience possible. App Store was created to be better and safer than the web. I have worked in a company that didn’t want to add IAP in their app initially and added a web-based subscription for a premium tier. Eventually, our CEO changed his mind and we implemented IAP. In the end, our customers won and have more choice.

Apple knows this, they know this rule was created to simplify payments, protect user data, and automate refunds. If Apple eases these rules, there would be no motivation for companies to maintain IAP. Every App Store app will switch to its own payment system. It’s going to be a disaster, just like the web. Yes, this will give more money to devs, but it will hurt Apple customers. Customers first, developers second. Instead of raising a public stink, the HEY app should do the same everyone else is doing, introduce a free tier or add IAP — they have many options which can improve their product.

Removing the fee is also a bad solution. Maintaining App Store curation is not free, and Apple has the right to take this cut, this is how capitalism works, and that’s what allows revenue growth. Playstation, Xbox, and Nintendo have been doing this for years and no one seems to complain.

The most common criticism is if the HEY app doesn’t allow to do it, why Netflix, Uber, and others can. They can because they are famous, Apple needs them. It’s better to have this inequality than allow everyone to charge money themselves. Unprecedentedly, Amazon added IAP for Prime videos, and if this rule wouldn’t exist, Amazon would never do it. I understand that Netflix can’t afford to lose 30% on every sale, they need this margin to invest in new shows. I think it is acceptable for popular companies like Netflix and Amazon to negotiate a lower fee, perhaps, even a zero fee. But this company has to be as big as Apple is.

What Apple could improve to make this matter better? Maybe they can deprecate StoreKit and allow Apple Pay for digital purchases. Maybe Sign in with Apple can play a role in this new system. It’s confusing, from a customer perspective, to have 2 different payment systems on a single platform. Why you can order food with Apple Pay but can’t buy a digital game? Refunds and subscription management would be problematic in this case, and it makes IAP a superior experience to a traditional credit card. Perhaps, if this is technically possible, and Apple could figure this out and augment IAP with Apple Pay, it could work.

MVC

Friday, March 6, 2020

I don’t think that we choose MVC often enough. Here and there I discover some podcast episodes and some articles which would tell a story of how MVC can be used successfully in a large iOS project. I cherish this moment because I think that MVC can work great while been misunderstood and undervalued by many iOS developers.

Bohdan Orlov has written this post on Medium about four iOS patterns: MVC, MVP, MVVP, and VIPER. Bohdan warns readers about the dangers of MVC and shows alternative pattern advancements. The table below with ratings on a scale from one to five from Bohdan’s perspective. One point is not given to any criteria — even the worst system is better than no system at all.

Criteria MVC MVP MVVM VIPER
Code size 5 4 3 2
Testability 2 3 5 5
Separation 2 3 4 5
Total 9 10 12 12

MVVM and VIPER have the most points. Seniors relying on unit tests, value separation, and don’t mind complexity. VIPER is too tedious and complex to keep up within big and medium teams, but MVVM often comes as a winner.

MVC is misunderstood. Most of the developers I’ve met told me that MVC is out of date, primitive, and not suited for modern needs. I don’t agree with them, I think that MVC is not causing the massive view controller problem when used as intended. Each view controller should serve only a single purpose. It’s not costly to add more than one view controller per screen. For difficult screens with many requirements func addChild(_ childController: UIViewController) can be used.

For me, product quality is the only thing that matters. I think that a maximum amount of effort should be put into making a product better through iterative improvements. View controllers are difficult and often impossible to test separately. Unit testing is generally good, but it shouldn’t drive the project design. Separating view controller and view model, designing a proper abstract interface between them helps with mocking but is extremely costly in code size and time. When choosing between less code and better code coverage, I would choose less code and I would write fewer tests. Simpler code is easier to maintain, it will have fewer bugs and it will enable the team to focus on refining the app. I think MVC can work great in many different scenarios, it integrates well with Apple frameworks, it’s easy to start with which helps with an iterative process.

Bohdan shows us that with each new pattern amount of code doubles. Each new pattern brings more abstractions and MVC wins with the least amount of them. I think the power of MVC in its simplicity. I wish we value simplicity more, it pays back a lot when debugging others people’s code.

Finally, I agree with Bohdan that we should think carefully before committing to a pattern, and don’t forget that it’s possible to use multiple patterns in a single project:

Therefore, it is natural to have a mix of architectures in the same app. For example, you’ve started with MVC, then you realised that one particular screen became too hard to maintain efficiently with the MVC and switched to the MVVM, but only for this particular screen. There is no need to refactor other screens for which the MVC does work fine because both architectures are easily compatible.

Page 2 of 11