Very strange day.

Working from home, unwell and isolated, while waiting on some clarity from the SQA.

Missing an entirely unexpected last day at school for many amazing pupils, and many more also cheated from their chance at sitting their exams.

Very strange indeed.

Day 46 of #100DaysOfSwiftUI: always reanimating

My Arrow view animated before I made it animatable. /shrug

Day 45 of #100DaysOfSwiftUI: Spirograph

Never had one of these as a kid, and now I have a simulation of one running in a simulation of a phone I have never owned. It’s turtles all the way down.

Day 44 of #100DaysOfSwiftUI: flower power

From Core Graphics to Metal and back again. A psychedelic story. The journey continues on, this time with rainbows. But no unicorns.

Day 43 of #100DaysOfSwiftUI: unnecessarily difficult

SwithUI Paths and Shapes use different coordinate systems? Is that to emphasise their difference? Or some reason as yet unknown to me? Explanations on a postcard please.

Stuff like this is why students find programming hard!

Day 42 of #100DaysOfSwiftUI: always seeking the ultimate answer

Today I learned that sometimes I can complete the challenges the ’easy’ way, and I am okay with that. No elegant, efficient solutions for me today. I blame the slow recovery from the lurgy.

An awesome World Tour stage race debut for Matthew Holmes (Twitter: @MatthewHolmes51). The new King of Willunga!

Day 41 of #100DaysOfSwiftUI: if a bug isn’t there, can you fix it?

I didn’t need to mess with LayoutPriority today, which is fine. Don’t know if I was lucky, or the bug was fixed in the latest SwiftUI release.

Day 40 of #100DaysOfSwiftUI: generic title

The programming toolbox has changed significantly since that first, lightweight Space Invader “clone” written a long time ago on a ZX81 far, far away. But 1KB of RAM. 1KB. Anyway, onwards and upwards.

Day 39 of #100DaysOfSwiftUI: obligatory mid-course review

The pacing of this course is excellent. Lifts and relaxes on a comfortable cycle, with built in consolidation and challenge days. If you are interested to learn SwiftUI then I heartily recommend the work of @twostraws.

Day 38 of #100DaysOfSwiftUI: discovering bugs?

On dismissing a sheet displayed from a NavigationBarItem button press, said button is inactive until there is some UI unrelated interaction, e.g. a scroll action. “Fixed” by displaying the NavigationBarTitle as .inline.

Day 37 of #100DaysOfSwiftUI: the mercy of others

All good. Today the weakest link was Xcode. How about syntax colouring just doesn’t work for a bit? And now autocomplete. Oh you think that code is valid?

stare at valid code without making changes

Okay, it’s fine now. Thanks.

Day 36 of #100DaysOfSwiftUI: property wrapper vs twitter handle

One of the things I like about Swift is the cleanliness that the language has tried to achieve since inception. Property wrappers and object bindings might not warp that, but they sure feel like they do sometimes.

Great intro to P vs NP-Complete from Jade at Up and Atom:

Is this thing that doesn’t look like this other thing really that thing?

Day 35 of #100DaysOfSwiftUI: challenged behaviour

Design is garish, code only somewhat modular, and I avoided animations. But 6 x 9 = 42.

I feel bad when I read tales from developers such as this:

As a Mac App Store developer whose apps have been in the store since the beginning, it’s not a great feeling to know that any critical update might be held up because Apple decided to get more uptight about something that was OK for the past 8 years. - Daniel Jalkut on Micro.blog

I feel even worse because it was the same weekend that Daniel emailed me to say he had changed some code which would hopefully remove an image uploading issue I was having with MarsEdit. And I had opted to purchase MarsEdit via the Mac App Store that very same day.

It hadn’t even occurred to me to purchase via his web site, even though he might have made a few extra dollars or cents that way. Like I have done so many times, I checked where it was available and defaulted to my purchase via Apple.

Woe is the Store of Apps for the Mac

I have read many an article telling us why the App Store is broken. And I am on board with those for the most part. I am sure it’s not perfect. Okay, I know it’s not perfect.

From the 30% cut that Apple takes from all sales, reduced to 15% for subscriptions lasting more than 12 months, to the technical restrictions with iCloud, sandboxing, etc. Not to mention¹ the lack of contact developers have with their customers. The list is long.

There have been well publicised cases of high profile companies leaving the Mac App Store, and then equally well publicised stories of some of them returning - no doubt, one has to think, with a little encouragement from Apple. I am sure this to and fro will continue for some time.

But…

Let’s hear it for the Mac App Store

The Mac App Store provides users with security. Of different sorts:

Not every Mac app is the greatest example of app development, and there is an argument that a greater degree of quality checking should be included in the app review process, but at least I can be reasonably assured that anything I install will play nice with my system and other applications. This means I am less likely to be installing a keylogger, virus, etc. I am less likely to putting the data on my Mac at risk to unexpected appropriation. My system and my data is safer.

I can more or less trust Apple with my banking details, at least in so far as I can trust anyone. Financially - compared to the wide range of developers that they represent who have not built up any relationship with customers - I am confident sharing credentials with them.

And as much as developers the world over would love to have a database of thousands of potential customers to leverage for marketing upgrades, their other apps, or other services, I am glad that this is something I have to opt into by signing up to a mailing list or otherwise connecting with the developer.

None of this is to suggest that Mac developers should not be trusted to write software, process payments, or manage a mailing list. Just that there are millions of people out there making software, and I think it’s good to have a proxy in place that can be trusted. I mostly don’t have to consider who the third party developer is.

And for those Mac owners who are new to the platform, or who lack confidence in the complexities of installing computer software, the App Store model offers all of the above alongside a unified search system² and one-click installation.

Thanks to Daniel

I would like to see changes to App Store policies, for both developers and users. But on balance, where possible, I will mostly likely continue to support developers through via the App Store rather than purchasing direct.

While we wait until Apple lowers their fees and is more transparent their app review processes, I am grateful to the developers who jump through the hoops to keep their software available in the Mac App Store. Thanks, Daniel.

Day 34 of #100DaysOfSwiftUI: always animated

I still have a ways to go with animations. Whether that is what animation to use, or how best to invoke them. It’s not a topic on which I have much dwelled to date. But…

Challenge complete, even if I didn’t provide much creativity.

Day 33 of #100DaysOfSwiftUI: fighting transitions

The Canvas live preview is great for making UI changes. But when it fails to display transitions correctly and you play with code for 30 minutes to try to work out why… and it turns out it works fine in simulator and on device.

Day 32 of #100DaysOfSwiftUI: you lost that animated feeling

If only the genie effect offered us three wishes rather than three approaches to animating views. Perhaps I need to clean that lamp. Or perhaps I need new wishes.

Day 31 of #100DaysOfSwiftUI: always avoiding work

Is it cheating to use map and reduce before they are introduced?

Take a good look at what you want to do, and try to come up with the long-term lazy way, not the short-term lazy way. (Larry Wall)