Introducing: Does the Elevator Work?
The elevator at the building I live in is broken a lot. To the point where residents on higher floors have negotiated with management to knock off a little rent from particularly bad months.
I thought it would be cool if the the residents could have a little status page where we update each other on whether or not the elevator is broken, plus see historical data on how bad the situation really is. One big Sunday of coding, plus a little bit on Monday and Tuesday, has resulted in this.
It's built with php and uses sqlite as the backing database. The visualizations have php programmatically outputing javascript which writes to an html canvas object. It's... disgusting. But I love it. And it works!
I had to learn a few things to get this thing made. Primarily reading and writing with databases, which php's pdo system makes pretty straightforward. But also doing password hashing and validation (so not just anyone can go in there and update things), and it was the first time I drew to an html canvas. And getting my server to let php actually talk to the database took some effort.
This is one of those projects where the journey was probably more satisfying than the destination. But early reviews from other residents have me hopeful. "Absolutely stellar," says one person in the group chat. "Priceless," says the cool older lady. "10/10" says the poor person who has to walk up ten flights of stairs every time the elevator breaks.
Now I just have to hope the building management either a) don't find it or b) don't really care.
The App Store is the Worst Part of Apple
Just got an email from the Apple Developer program detailing a few updates to their review guidelines. And hey, it sounds like good news: in the US, developers can accept payments outside of the in-app purchase situation that's been a requirement for years. Progress! Right?
Except.
There had to be some catches. This was a result of a court order, so clearly they're not doing this willingly. And although it's now technically possible to take a credit card payment in your app that avoids giving Apple 30% of your money, it's functionally impractical-to-impossible.
You have to:
- Still offer in-app purchases through their system (for their 30%)
- Request and be issued an entitlement, that you need to implement in Xcode
- Provide exactly one URL that cannot change without re-review
- Format the button to press in a way that makes it not at all look like a button
- Use a specific icon at a specific size as part of the button's text
- Accept that Apple will throw up a very scary wall of text saying you're probably about to get scammed despite having checked that the URL is safe during review
- Accept that Apple will now "only" take 27% of your money instead of 30%
Failure to do any of these things to their exacting specification will get you rejected. There are some weasel words in the guidelines, like how the link out icon size "must visually match the size of the text," which could mean anything to anyone and will definitely result in rejections. And you still have to provide Apple with a report of all your earnings each month so they know you're giving them their 27%.
This all matches what happened in the Netherlands with dating apps, where Apple decided that if they were to comply with these court orders, they'd do so in a way that made it as painful as possible for both developer and consumer.
The App Store is the worst part of Apple.
The deal with Apple, for a long time, was easy to understand. You'd buy a Thing, and that Thing would be different in some way from the things it was competing with on the market in a way that made it desirable. It was easier to use, or looked nicer on your desk, or made you look cool to use it, or had a nicer way of interacting with it, or had software that was nice to use. You'd pay more for it than the other things on the market, because it had those benefits.
But then, the iPhone got huge. All the software that got created for it was a big part of that. But Apple couldn't see that software as a benefit to the ecosystem, despite the ads. Infamously, the guy running things saw any money being made in the ecosystem other than by Apple itself as a parasitic situation. Every dollar earned by some parasite on the system, like, say, developers, would have to be fought for.
That attitude stuck with the App Store leadership, it seems. Rather than accept the situation for what it is – that only having one software vendor for a platform is unacceptable – the folks running the App Store have decided to make the march to independence from the App Store as poisonous a process as possible. They'd rather make the experience of developing for and using the product terrible than give up 30% of ninety-nine cents.
It's gross, and it's not going to stop until a judge decides that this kind of crap isn't good enough. Or maybe the right couple of old guys retire.
Feeling Dumb for a While
It's always tough to learn a new set of tools. It's especially tough to learn your second set of tools. The first was the only way to do it for a long time, after all.
Doing the full conversion of NMR Solvent Peaks from UIKit to SwiftUI was one recent example. It took me most of a summer just to get the flow right. Easy things became hard, and it was frustrating. I bounced off of it more than once and just figured I'd go back to UIKit. But I got the hang of it eventually, mostly by just trying to make the thing I wanted to make instead of a million sample projects and tutorials. Every time I hit a snag, I'd search through Stack Overflow or Hacking with Swift and get an answer to that particular issue. There were many such searches on the first day. There were fewer over time.
Eventually, those easy things that had become difficult with the new tools? They were easier than before. And problems I avoided because of the complexity? They were within reach now.
The same sort of thing is happening with me and 3D modeling. I've been using TinkerCAD for a long time to design things to 3D print. But it's pretty inelagant. Just about everything is a combination of basic shapes and their intersections. Now, I could build some pretty cool stuff with TinkerCAD. Two of which I'm proud enough of to publish on the internet, and it's really satisfying to see people print them for themselves. But there has always been a huge shadow hanging over all of these designs: what if I put on my big boy pants and used Fusion 360?
Well, I had tried Fusion 360 a few times already. Each time, I bounced off of it. Simple operations in TinkerCAD didn't seem possible in Fusion 360. And years of using TinkerCAD had trained my brain to think of 3D objects as constructions and combinations of simple shapes. So the entire design system of Fusion 360 was foreign to me.
But just like with SwiftUI, once I sat down and gave it a real try with a real project, it turns out that those operations were actually possible. And with a bit of time, easier than in TinkerCAD. I just had to rewire my brain a bit, and be willing to feel dumb for a while. But here's the best part – now, things are possible for me in Fusion 360 that were absolutely impractical in TinkerCAD. Pulling in faces a bit for fit tolerances required completely rebuilding a part in TinkerCAD. In Fusion, it's like four clicks. But then extending one face in a 3D trapezoid pattern to fit in a similar 3D trapezoid hole in another part? More or less impossible in TinkerCAD. In fusion, again, it's like four clicks.
Learning new tools stinks. It would be so much easier to just get my work done with the old tools. And I have to feel dumb, despite being good enough with the old tools that feeling dumb felt like a distant memory. But most of the time, once I figure out how to solve the old problems with new tools, I realize that there are new classes of problems I never even considered solving because the old tools couldn't handle them. It's not just about solving old problems faster, it's about rewiring my brain to find new ones to solve.
I just wish it didn't stink so much at first to feel dumb again.
App Store Conspiracies
I'm really not a fan of Apple's App Store policies. This is not a revolutionary statement. Ever since the App Store launched, the 30 percent don't-call-it-a-tax has felt pretty crappy to anyone developing on the platform. But all of that cash can't seem to fund decent App Store review infrastructure, with good apps rejected all the time for no reason and absolutely terrible apps making it through all the time. How can they be raking in billions of dollars, mostly from gambling apps for childeren, and not be able to pay people to properly filter out the garbage?
But, then (Christopher Atlan, via Michael Tsai):
My sources tell me Google has successfully inserted provocateur agents inside Apples App Review team. They are exceeding their goal to discourage indie devs, making these remarkable apps for the Apple platforms.
So this kind of conspiracy theory stuff is probably wrong. But it's believable, kind of. At least I want it to feel believable. I'd certainly prefer that the App Store to be a good place to distribute software. But it's not. As to why, it's easier to imagine that a few bad folks are ruining it than acknowledge that the whole place might be rotten. You can get rid of a few bad people.
But, really. Is App Review being torpedoed by secret Android fans on the inside? I think the simpler explanation is probably right. The incentives for App Review being terrible just outweigh the benefits of fixing it. Thirty percent of gambling apps for children, scams, and all of that adds up to a lot.
The Beginning of NSP 3
I've begun the great migration of NMR Solvent Peaks to SwiftUI.
I have looked into porting the iOS / iPadOS version a few times, and always hit hard walls. Not being to place certain views where I wanted was the primary problem, but there were others. But three things have changed:
- A redesign of the main interface renders many of the issues I had before moot
- I've worked around some of the SwiftUI problems to put things where I want them
- The rest of the problems aren't bad enough to warrant a workaround (read: a pile of hacks)
To my surprise, I could have done this all last year, since none of what I've written (so far) requires the iOS 16 improvements to SwiftUI. The main thing motivating me is the message from the WWDC '22 Platforms State of the Union: AppKit and UIKit will be around for a while, but they're old news.
I'm not sure it's the same sort of transition as Carbon to Cocoa back in the early Mac OS X days. Carbon absolutely went away for good in Snow Leopard, but SwiftUI "compiles down" to AppKit and UIKit components in the background. The only way those frameworks are going away is if SwiftUI actually runs natively on their platform, and I don't think that's happening any time soon.
I'm only partway through the porting process. But the underlying model code doesn't need to change at all (it's still Swift, after all). Porting over the multiplet drawing code wasn't as hard as I thought it would be. And the overall design for the main interface is starting to come together. In the next few weeks, I'll see if I can get it across the finish line. Hopefully it'll be ready when iOS 16 drops in September or October.