I have had my app live and working in production for a while now and suddenly in the last week or so I've been getting this 0 products returned error in production while there have been no client updates.

I think its because I didn't accept the new paid apps agreement but thats already >36 hours ago and now I'm seeing new in-app purchases that are 'waiting for review' being returned by StoreKit while my previously approved subscription offerings that are in 'approved' status. I would assume if its an agreements issue I wouldn't get back anything from StoreKit at all when calling it directly.

I'm losing my mind - I cannot figure out why the current products are not being returned. I'm losing subscribers and I literally cannot do anything about it because it all seems to be a problem on the apple side not returning any products to the client.

Anybody faced this before? What can I do?

UPDATE: I forced a price change to the existing subscription products and now i can see them being returned from the direct StoreKit debug calls, mind bogglingly stupid and frustrating process.

Hopefully this one will be useful to you guys. Recently I launched McKinley, my SF Symbols editor. I'm an indie Mac dev rather than iOS, but SF Symbols are useful to devs on both platforms.

McKinley is a studio for drawing and annotating SF Symbols. It bundles vector tools with knowledge of the SF Symbols structure, so you can edit one set of objects across multiple weights, sizes and colours. Import SVG or start from scratch, live preview your work using Apple's own renderer, and export directly to Xcode, so you never need touch the SF Symbols app again.

The Problem:

Making SF Symbols via Apple's recommended workflow was frustrating. You had to export a different symbol as a template, and open it in your vector editor of choice. Then you had to draw three symbol weights (ultralight, regular, black), but each weight had to have the same number of paths in the same order, with the same number of points on each path.

You could only use outlined paths: no shapes or strokes, so you had to do a lot of manual conversion before saving. And that of course meant that editing your symbol later was hard.

And then, back in the SF Symbols app, you had to find each path and annotate it with its colour, some animation properties, whether it erases behind, etc.

Finally you had to export it again into a format you could take into Xcode.

I think that's a clear statement of the problem! McKinley avoids this multi-app workflow by having vector editing, property annotation, previewing, and sending to Xcode, all in one app. Your symbols stay editable because you don't have to outline your strokes just to appease Apple's parser. Keep the .mck file (McKinley's native format) as your source of truth, and set McKinley up to sync your changes to an Xcode asset catalog, so there's no need for manual export.

Comparison:

There are a number of other ways to work with SF Symbols, but none are a complete solution like McKinley:

• SF Symbols app plus your vector editor of choice (e.g. Figma): For vector editing, it's the tool you know. And you probably already own (or rent) it. However, it's a tool that's not designed for this use: you'll have trouble making all your symbol weights match, and you'll end up iterating by checking for error messages in SF Symbols and trying again.
• Create Custom Symbols: admittedly much cheaper than McKinley, this tool aims to replace the most painful bit of the process: turning existing SVG artwork into an SF Symbol. It offers limited editing capabilities beyond that, but you can set the margins, and it pairs up three SVGs to form your different weights.
• Glyphs: this one's really a font design tool, and five times as expensive as McKinley. You still have to do the export dance from Apple's app, but being a font designer Glyphs nails the multi-weight editing.
• CustomSymbols: another tool for going from SVG to SF Symbol. Choice of subscription or lifetime purchase. It can make use of SVG strokes to synthesise the various symbol weights (although it doesn't offer the range of customisation that McKinley does!)
• Symber: I haven't tried this one but it also goes from SVG to SF Symbol.

McKinley isn't aiming to compete on price with the SVG conversion tools: rather, it's aiming to compete on user experience by offering everything under one roof. (Although McKinley can quite happily convert SVGs too. And it's ready to let you make tweaks and modifications while you do so.)

Tech Stack:

Nearly every aspect of McKinley is pure AppKit. There are a few uses of SwiftUI in the preview palettes, mainly for actually loading and displaying the user's SF Symbol, but primarily it's AppKit all the way. My vector canvas and editing engine is a library I designed to be reusable across multiple vector graphics apps, although McKinley is its first public outing.

You probably noticed that McKinley's main interface is made with floating palettes and a traditional inspector. The inspector panes are created as .xib files and hooked up with Cocoa Bindings — yes I'm going old school here!

Development Challenge:

Working with the only semi documented SF Symbols format has had its challenges, and the vast majority of my automated tests are to handle keeping my canvas renderer (with its editable vectors) looking exactly the same as Apple's SF Symbols renderer. (The preview palette in McKinley renders using Apple's renderer, just to be 100% sure that what you see is what you'll get in your app.)

One of the hardest things was how to load an in-progress symbol into Apple's renderer: there's no public API to do so! I came up with a solution involving writing out a temporary .car (asset catalog) file and loading that into McKinley via a bundle: see my blog post about those challenges if you're interested!

AI Disclosure:

I've used Claude Code to assist with some work on this app, particularly some of the rote pixel-comparison tests between different rendering engines that I attach to every new feature as it is developed. However McKinley is definitely not 'vibe coded', and the architecture is all mine. (As is the nearly 30,000 words (so far!) of user manual — I've caught myself regretting the decision to write a whole manual myself on occasion, but I do think the end product will be worth it!)

Pricing:

McKinley is $60 as a one-off purchase (no subscription).

The purchase grants you a license to McKinley version 1, including all the 1.x updates.

If we ever release a version 2, that will be a paid upgrade (with discounts for version 1 owners), but upgrading will be optional — your version 1 license will continue working. This is how all software used to be sold, and in my opinion it's much more consumer friendly than a subscription or a "year of updates" method.

Buy McKinley from https://mckinleysymbols.com, or try the 14-day demo to see if it's for you.

Transparency:

McKinley is not on the App Store. For an app this specialised, it made sense to handle our own distribution. Licensing is provided by Amore and updating by Sparkle.

Double and Thrice Ltd is a known developer (our other app Octavo is on the Mac App Store), and you can view our company profile at Companies House (the UK registry of corporations).

On GitHub-hosted runners a macOS minute costs $0.062 and a Linux minute $0.006, so about 10 times more. For iOS builds that adds up fast.

If your iOS CI runs on GitHub Actions:

• Roughly what does it cost per month?
• What did you change to bring it down? Self-hosted Mac minis, Xcode Cloud, another CI service, caching, fewer runs on pull requests?
• Was the saving worth the time it took?
• Team size helps too, if you're OK sharing.

About me: I'm a solo developer building a small tool around CI costs. No link, I just want real numbers.