My app lets users create things with text, and I've included Apple fonts so users can format their text with them. These were fonts I found in the Font Book app that comes with macOS. My assumption is that these, like the San Francisco font, can be distributed with apps. Do I need to attribute these fonts to their creators and publish a license in my "About" page? If so, where do I find the license(s) and what is the proper way of publishing them? Is there anything else I should know? Please let me know if this should've been posted under a different topic and tag

Private Access Tokens (PATs) are headlined as something that can eliminate CAPTCHAs, but also includes app-to-server communications in its use cases. Because of this, they seem to perform a very similar function to DeviceCheck, since both aim to attest to the health of the device in question. I don't really understand the difference between the two and find this confusing. Since PATs are newer and more general, I'm more inclined to adopt them, but where does this leave DeviceCheck? Is it redundant? How does App Attest fit into all of this? If my goal is to minimize if not eliminiate fraudulent/malicious use of my app's APIs, should I use Private Access Tokens, DeviceCheck, and App Attest simultaneously to maximize my protection? If not, what is accepted to be the best practice? I admire Apple's dedication to privacy and security, but as a new developer I feel Apple could make it easier for their app developers to find out and implement the latest best practices.

I'm a new app developer and I've read through most relevant posts on this topic here and elsewhere. Many of the forum posts here are specific to Objective-C, or old enough to be considered outdated in the fast-moving world of computing. Many of the posts elsewhere are about protecting authentication secrets, which doesn't apply in my case, and a lot are by someone with a product to sell, which I've ignored. My app is 99.9% Swift and I'm not going to store any authentication secrets in the IPA. What I'd like to protect is the core mechanism of my product, which has to be included in the binary and is small (< 10k lines). I want to make it so it's harder to steal the source code than it is to recreate my functionality from scratch, which is difficult even with the app in front of them. From what I gathered, Swift code compiled by Xcode is protected from reverse engineering / decompilation by the following: Symbolization of the app Native builds from Xcode destroys names of variable, functions, etc. Swift code is compiled in such a way that makes stealing harder than Objective-C This should make me feel better, but the threat-level is increasing with the availability of free, commercial-grade decompilers (e.g. Ghidra) and machine learning. The fact that iOS 18 supports a checkm8 (i.e. jailbreakable) device means that decrypting the IPA from memory is still trivial. Questions People talk about stealing authentication secrets via reverse-engineering, but is the same true for mechanisms (i.e. code)? How common is the issue of source-code stealing in iOS apps? Can machine learning be leveraged to make decompilation/reverse engineering easier? Will I get rejected by App Review for obfuscating a small portion of my code?

My app stores and transports lots of groups of similar PNGs. These aren't compressed well by official algorithms like .lzfse, .lz4, .lzbitmap... not even bz2, but I realized that they are well-suited for compression by video codecs since they're highly similar to one another. I ran an experiment where I compressed a dozen images into an HEVCWithAlpha .mov via AVAssetWriter, and the compression ratio was fantastic, but when I retrieved the PNGs via AVAssetImageGenerator there were lots of artifacts which simply wasn't acceptable. Maybe I'm doing something wrong, or maybe I'm chasing something that doesn't exist. Is there a way to use video compression like a specialized archive to store and retrieve PNGs losslessly while retaining alpha? I have no intention of using the videos except as condensed storage. Any suggestions on how to reduce storage size of many large PNGs are also welcome. I also tried using HEVC instead of PNG via the new UIImage.hevcData(), but the decompression/processing times were just insane (5000%+ increase), on top of there being fatal errors when using async.

I'm trying to add JPEG-XL encoding/decoding capabilities to my app and haven't been able to find a trustworthy pre-compiled version. The only one I've found is in https://github.com/awxkee/jxl-coder-swift. As a result I've been trying to compile my own iOS version from the reference implementation (https://github.com/libjxl/libjxl), having done virtually no compiling before. When I started out, my gut said, "Compiling for a different platform should be easy since it's not like I'm actually writing or modifying the implementation", but the more I research and try, the more doubtful I've become. So far I've figured out it means compiling all the dependencies (brotli, highway, libpng, skcms, etc.) too, but I've also gotten nowhere with them, having tried my hand at modifying cmake toolchains and CMakeList.txt files. As a novice, am I biting off more than I can chew with this? Is the seemingly simple task, "Compile this C++ library for iOS" actually something that freelancers charge huge amounts for? (If so, this makes the free compiled version mentioned above even more questionable) Any help or pointers would be greatly appreciated.

I'm making a loading screen, but I can't figure out how to make the loading indicator animate smoothly while work is being performed. I've tried a variety of tactics, including creating confining the animation to a .userInitiated Task, or downgrading the loading Task to .background, and using TaskGroups. All of these resulted in hangs, freezes, or incredibly long load times. I've noticed that standard ProgressViews work fine when under load, but the documentation doesn't indicate why this is the case. Customized ProgressViews don't share this trait (via .progressViewStyle()) also choke up. Finding out why might solve half the problem. Note: I want to avoid async complications that come with using nonisolated functions. I've used them elsewhere, but this isn't the place for them.

I need a magnifying glass function for one of my SwiftUI Views, but can't find a way to implement it as needed. I found a Youtube video where the author renders the view twice, overlaying the second over the first, then scaling and masking it to create the illusion of magnification, but this is expensive and doesn't work in many cases where more complex views are presented (e.g. a LazyVGrid). I've also explored continually capturing partial screenshots and scaling them up to create the illusion of magnification, but there's no straightforward way to achieve this with SwiftUI without getting into the messiness of UIViewRepresentables. Any help would be greatly appreciated

Hello, I'm a Canadian living in Hong Kong who has attempted to enroll in the developer program. After submitting my Canadian passport as identification, I was told it's not valid ID for the region (Hong Kong) and that I should submit something else.  I have several concerns that I would like answers to so I can figure out how to proceed: I'm very likely to move back to Canada in the near future and would like to know if there are any issues associated with switching between App Store regions? Issues like having to pay for enrollment twice, or legal/regulatory problems, or anything else? Another concern I have is my app being somehow subjected to censorship or some regulation that escapes my common sense, since Hong Kong is part of China.  My apps are not political but this is still a point of concern given the recent crackdowns on its tech and education sectors--it's not entirely unthinkable that something will strike down my app out of the blue, for no fault of my own. My app is intended for a global audience, but I fear having my developer account tied to Hong Kong (China) will come back to haunt me in some way. Am I fretting over nothing? There's also the payment issue--can payouts from my app be sent to an bank account of my choosing, or does it have to be in the region I'm tied to? Thank you in advance for your time.

I'm looking to use high-quality and large images as animated sprites via SpriteKit. Is it possible to display sprites with HDR colors in SpriteKit? What about SpriteKit via SceneKit or RealityKit? I've looked all around and it seems as though *.PNG is the only accepted image format, and it doesn't seem to have HDR support.

I'm looking to use high-quality and large images as animated sprites via SpriteKit. Right now the default maximum size of a texture atlas is 4096*4096, which is at least an order of magnitude below what I need. There's an option to create custom maximum sizes, but the tiny default and the age of the SpriteKit framework is giving me second thoughts even though I'd very much like to stick with an Apple framework and not have to rely on another party like Unity. Before I invest my time and energy into SpriteKit I'd like to know whether the decade-old framework, running on modern hardware (A11 and newer), can support massive texture atlases while maintaining decent performance (~30 FPS). If not, is it possible to implement something similar in less antiquated frameworks, such as RealityKit (non-AR). Thanks in advance for your time.

I’m trying to build a simple app that will allow users to create items in-app and buy/sell access to them. Users can buy tokens from the App Store that can be used to fund these purchases (e.g. 1 token = 100 coins), and can also be used support the development of these items (e.g. give creator 1 coin a week). The creators can then cash out the coins once a certain amount is reached, via Stripe or some other external payment provider. Is this allowed under the current rules of the app store? Is it possible to implement using CloudKit? If this isn’t allowed, is it possible to allow users to share content on the app’s “store” for other users to browse and download, and can that be done just using CloudKit? This is my first-ever app and I don’t know left from right when it comes to back-ends. I will greatly appreciate any pointers.

My app uses SpriteKit and requires the use of SKTextureAtlas for performance. However, it uses user-generated content, which means that atlases don’t initialize using bundled images, but instead have to recreate all sprite sheets, leading to long loading times. Is it possible to save the sprite sheets made from user-generated content to disk so that SKTextureAtlas can load them instead of recreating all sprite sheets upon every initialization? Is there any alternative solution to this problem? For example, is there a way to dump a bunch of images into memory to use as a texture pool and keep them there until deallocated?

I'm a new developer and I can't decide whether CloudKit or Firebase is more suited to my app's needs. The general vibe I'm getting from multiple sources is that CloudKit is purely for storage, but that seems off to me, so I'm hoping to find some hints or answers with regard to my specific use-cases. My app allows users to create multimedia objects that are stored somewhere and displayed in the app's marketplace, with use access granted to those who decide to spend tokens on them. These multimedia objects can go up to a few gigabytes. Ownership of these objects are tracked via a user account database. Am I correct in assuming that my app's CloudKit public database can be used to store, check user request validity, and distribute these multimedia objects? Can it also be used for the management of user accounts and overall token counts? Additionally, is it possible for the app's administrators to pipe data out of the public database for analysis and to payment processor APIs? Any help would be greatly appreciated

Hello, I'm making an app where users can create a multimedia object and other users can use in-app currency (purchased via in-app purchase) to gain access to the object. They can also choose to subscribe to a creator to encourage and support their content creation. Tokens can be converted to cash and sent to creators. It is unclear to me whether this violates app store rules. After reading through the App Store Guidelines and searching through the forums (this thread was close to what I was looking for), I have yet to arrive at a clear answer. The Guidelines state that "tipping" content creators is acceptable, but this isn't exactly what I'm looking for in a creator marketplace. The Business section doesn't contain anything else that seems relevant, and this makes it seem like only voluntary tipping of content creators is accepted. The commerce engineer in the thread linked above discourages using in-app currency, but that doesn't seem to work for my use case (the thread's creator wants to use the IAP mechanism). Furthermore, IAP cannot be created programmatically (i.e. by users) and is error-prone. It must be stressed that I'm not trying to deny giving Apple its 15-30% share, since users must buy in-app currency using Apple's IAP (this is not a multi-platform app). Cash in the app's economy has only one entry point, and that is via Apple's IAP. I have asked a similar question recently, but received no response. This is probably because I didn't phrase it well enough and didn't attach the correct tags. Creating the infrastructure for a creator marketplace app is a lot of grueling work, and I would very much like to know whether my app will be rejected for it before I embark on this quest. Any help would be greatly appreciated. tl;dr - Is the ability to make in-app currency purchases of creator content a violation of app store rules?

The 10th-Gen iPad differs from its predecessors by having a camera that's located at the top of its landscape orientation. This is a headache for me since my app needs to know the rough camera location given the device's orientation for AR purposes. I can find out whether the device is a tablet or not, but I can't find out whether it's an iPad 10. Are there any direct or indirect ways for me to find out whether a camera is placed for portrait or landscape use?