Blog posts tagged #code


The App Store is the Worst Part of Apple


#code

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


#code, #3d-printing

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


#code

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.


Another Blog CMS


#code, #meta

I haven't written anything here in a bit, and it's again because I've been fighting the tools.

I've gone through and converted this blog to use the Grav CMS, with a heavily-modified version of the Hypertext theme. I like it a lot more than previous attempts:

  • My first, from-scratch, git-based CMS. It did exactly what I told it to do, which was great but also sometimes a problem. Not having a web backend stunk.
  • The second, Automad-based system. Automad is great. But I couldn't bend the theming system to my will, and persistent permissions issues on the server prevented me from really using it. Likely PEBKAC but I couldn't get it to work.

This system feels better. Grav uses the Twig templating engine, and as I've made edits to the theme, I find myself filling the site with little curly braces. It's odd to have Twig get processed down to php, which then generates the actual html. You'd think it's not super efficient, but Grav also implements decent cacheing, so it works out all right.

I really hope this one works out. My other options are less desirable. There's always old reliable.


The Beginning of NSP 3


#code

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:

  1. A redesign of the main interface renders many of the issues I had before moot
  2. I've worked around some of the SwiftUI problems to put things where I want them
  3. 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.


Version Control


#meta, #code

I think it's finally time for me to learn git.

I have been writing code that goes out into the world (starting with NMR Solvent Peaks) for about five years now, and I'm not proud to say that I haven't been using any form of version control. Nothing I do is complex enough to really need it, and it's just me.

But that's not sustainable, obviously. If I'm ever on a team of people working on a project or if I don't trust my edits (and boy howdy should I not trust my edits sometimes) I'm going to need to get good at it.

So the plan is to put the contents of this blog under version control. The code should definitely be under version control, but I'm also going to use it to send new blog posts to the server. Regenerating all of the html files will start by pushing down edits and new files, then parsing and writing html. I'm going to host the repository at Github for now, since it's there and I can write (or paste) right in their text editor.

And if it all blows up, well, hopefully I can roll back.

Edit, some time later:

This post, and this edit, were both pushed to the server by using git. Success!

Edit 2, in January of 2023:

This system turned out to really stink.


Serial, not Parallel Projects


#code, #meta

I'm at the part of this blog engine project where I think I can see all the parts that need to be built, but they haven't been built yet. This is a dangerous place to be.

I have the Xcode 14 beta downloaded and ready to go. iOS 16 is calling. New SwiftUI functionality is making it harder not to just sit down and rewrite NMR Solvent Peaks from scratch. Maybe it'll be better this time? Or maybe it'll take longer to hit the brick wall of "you can't do that" functionality.

No, I will be strong. There are still plenty of lines of echo $blah to write.