Hello I recently discovered that Denmark's (and soon the rest of the Nordic countries) biggest mobile payment service - MobilePay - is seemingly getting away with selling digital products in their app without using IAP. I am confused how this is possible, as I spent a lot of time making sure I understand the rules -- and I'm quite confident I do, so the only conclusion I can reach from this is that this is a violation that has not been discovered. If it isn't, I would like an explanation. So, what am I talking about? First; MobilePay is an app that lets you send money to whoever, essentially a Danish version of CashApp. You attach a credit card, and you can transfer funds using people's phone numbers. Nothing about this is problematic. There are some fees involved, which is also fine. But. You can select to "wrap your money in digital wrapping paper", which can be unwrapped by the recipient to reveal the amount you transferred. This is, no matter how you spin it, a digital product. It adds about 1 USD to the transferred amount, but that amount goes directly to MobilePay, not to the recipient - and isn't a transaction fee. To me that sounds exactly like the kind of payment that is absolutely mandatory to process via IAP - so how are they not? How does it pass app review? Is there something I'm missing? As someone who has been forced to use IAP for a service I would much rather not share the revenue of with Apple, I find this frustrating, and I'd prefer that everyone was subject to the same rules, especially when it comes to big corporate players like the developers of this app. You can read about the conditions of buying digital wrapping paper here: https://mobilepay.dk/app/legal/trading-conditions-da-dk - this page is in Danish but should be easily translatable. A theory I had is that maybe this wrapping paper feature is just not available to the test user they provided to Apple, as it is only sold to customers in Denmark and Greenland. But that's almost worse than an oversight, because in that case, they deliberately hid it from app reviewers. I have attached some photos of how it looks when you select the product in the app and how it just adds the cost on top of the amount you chose to transfer. I just chose a sample transfer of 1 DKK for the amount itself, and the 7 DKK for the "paper" is then added on top. It's not a lot, but given the size of the app's userbase (over 4.5 million according to themselves), we're likely talking a significant chunk of change they're essentially (if you're being cynical) stealing from Apple. What gives? For reference, the app in question is this one: https://apps.apple.com/dk/app/mobilepay/id624499138?l=da (currently ranked 4th in Finance in Denmark)

Hello After updating my/our devices to iOS 17 (or XCode 15, not entirely sure), the custom fonts in our application have started randomly not working. Usually it will happen after the app has been in the background for a while. What happens is that: The fonts either don't load at all. For icon fonts, this means a lot of question marks. The fonts get swapped around, meaning regular text (Roboto, custom font) starts rendering using the icon font (Font Awesome). I can tell because I recognize the font from development. I have no idea how to reproduce it. I tried simulating the memory warning on the simulator, but that doesn't trigger it. It did not happen when building for iOS 16 and I did not change any font logic since then. It still does not happen on devices running iOS 17 but on versions of the app built with XCode 14. Some debug info: XCode: 15.0.1 (15A507) iOS: 17.1.1 (real device, I have not observed it on Simulator) We load the custom fonts from a proprietary SPM package: fileprivate static func registerFont(fontName: String, ext: String = "otf") { guard let fontURL = Bundle.module.url(forResource: fontName, withExtension: ext), let fontDataProvider = CGDataProvider(url: fontURL as CFURL), let font = CGFont(fontDataProvider) else { fatalError("Couldn't create font from filename: \(fontName).\(ext)") } var error: Unmanaged<CFError>? CTFontManagerRegisterGraphicsFont(font, &error) } public static func registerFonts() { registerFont(fontName: "Font Awesome 6 Brands-Regular-400") registerFont(fontName: "Font Awesome 6 Duotone-Solid-900") registerFont(fontName: "Font Awesome 6 Pro-Light-300") registerFont(fontName: "Font Awesome 6 Pro-Regular-400") registerFont(fontName: "Font Awesome 6 Pro-Solid-900") registerFont(fontName: "Font Awesome 6 Pro-Thin-100") registerFont(fontName: "Font Awesome 6 Sharp-Light-300") registerFont(fontName: "Font Awesome 6 Sharp-Regular-400") registerFont(fontName: "Font Awesome 6 Sharp-Solid-900") registerFont(fontName: "Roboto-Medium", ext: "ttf") registerFont(fontName: "Roboto-Regular", ext: "ttf") registerFont(fontName: "RobotoMono-Regular", ext: "ttf") } // Similar methods for all font types and icons: @objc public static func getDefaultFont(size: CGFloat) -> UIFont { return UIFont.init(name: "Roboto-Regular", size: size) ?? UIFont.systemFont(ofSize: size); } This code is the called in didFinishLaunching, and it would crash the app if it failed: FontHandler.registerFonts() To reiterate, all the fonts work when launching the app. Restarting the app always fixes it, which, combined with the fact that they get swapped around, leads me to believe that it's some kind of font caching issue. We use the fonts in code-only (no storyboards or xibs ever). A font would be loaded like this: let label = UILabel() label.font = FontHandler.getDefaultFont(size: 15) The font files ship with the SPM package itself, which contains the FontHandler class used above. import PackageDescription let package = Package( name: "MyPackageName", defaultLocalization: "en", platforms: [ .iOS(.v11) ], products: [ .library( name: "MyPackageName", targets: ["MyPackageName"]), ], targets: [ .target( name: "MyPackageName", resources: [ .process("Fonts") ]), .testTarget( name: "MyPackageNameTests", dependencies: ["MyPackageName"]), ] )

HelloOur app does not allow users to register from within the app. They must register elsewhere (on our website) and can then use the app after the fact. We use Facebook login, which would require us to implement Sign In With Apple, but this leaves us in an odd situation that we don't know how to solve as we're not sure of the rules.Currently, if you log in with a Facebook account that has no ties to an account, you will not be allowed to proceed and you must use your Facebook account when you sign up on our website. Or if you already have an account, you must go to our website, log in and then connect your Facebook account. Our plan is to implement a similar logic for Sign In With Apple, but *something* tells me this would not be acceptable to App reviewers.There is no good solution for this. For a strict "Apple login must work" workaround we can let users sign in with Apple and access a user account that has no content and serves no purpose. Our app is not meaningful in this way and it will lead to confusion: Our system is a SaaS which makes it impossible to onboard users inside the app, as the app cannot be used unless you've already been granted access to the SaaS platform by an administrator.Would it be acceptable to reject a Sign in With Apple request if no user account exists? Remember that this is equivalent(*) to how Facebook is implemented, which is what the app review guidelines indicate as the requirement . Could we ask testers to provide an Apple user ID that we can connect to a user in our database for the login-flow to work correctly?(*)Apps that use a third-party or social login service (such as Facebook Login, Google Sign-In, Sign in with Twitter, Sign In with LinkedIn, Login with Amazon, or WeChat Login) to set up or authenticate the user’s primary account with the app must also offer Sign in with Apple as an **equivalent** option.