I'm having a lot of trouble getting my icon working with XCode26 and Icon Composer. <TL;DR> The icon sucks </TL:DR> Why does it suck? 4 main issues plague me when I compare the new icon with the existing icon. The colors are washed out. I can't have a transparent background. The size of the icon is wrong. I can't use the old icon on pre-Tahoe macs. It's Tahoe or bust! Here's a comparison between the two icons: If I add any Liquid Glass effects to the icon, it just looks bad. Any more of a gradient behind the image makes the image fade out. Adding specular highlights just throws a ring around the upper and lower sections that doesn't seem to fulfill any purpose. Blur doesn't seem to do anything. And I can't get rid of the background at all. It must be there. The biggest problem is the size. The new icon doesn't just look smaller, it is smaller! I measured the width and the new icon is 19.5% smaller. I did this by setting the finder view to 128x128, grabbing the screen shot, and using Acorn to measure the width from the left red edge to the right blue edge. The icns file is 256 pixels across which makes sense as I'm on a 4K monitor at 2x resolution. The icon file is 206 pixels. Doing the same with the finder set to 256x256 shows the same reduction. When I look at Icon Composer, it's showing me that the icon is fitting in perfectly with the guidelines. The graphic artist I hired years ago did a great job! So somehow there is a border being added to the icon file that shrinks the image down, and I can't get rid of it nor make the icon bigger. So I'm stuck. I've tried the various tricks to get both the icns and icon files to be added to the build such that pre-Tahoe macs see the old icon, and it either breaks on Tahoe or breaks on the pre-Tahoe. I can't get both. I don't think there's a solution to this, I'm just documenting my frustrations. The Mac was fine before this, why change something that works?

Ok, I'm going crazy here. I have a static library for iOS that I want to build for the simulator. I use xcodebuild -destination="iOS Simulator" and then check the library using otool which tells me the platform is 6, which is Mac Catalyst. When I look at the output of xcodebuild, it says --- xcodebuild: WARNING: Using the first of multiple matching destinations: { platform:macOS, arch:arm64, variant:Mac Catalyst, id:00006041-0008492E3AA1801C, name:My Mac } ... It has the simulator listed too, way down the list: { platform:iOS Simulator, arch:x86_64, id:AB7A99B3-8D24-4F73-A42D-9BB45321928D, OS:18.6, name:iPad (A16) } When I put all of that into xcodebuild for the platform, it still says there are multiple matching destinations and chooses Mac Catalyst. Why? How? What? Does platform="iOS Simulator" mean nothing? How in the world does "Mac Catalyst" match "iOS Simulator"????? I don't want Mac Catalyst, I don't need Mac Catalyst, and I can't get rid of Mac Catalyst. Nothing I specify in xcodebuild results in anything I can build that will compile for the simulator. What the heck am I doing wrong?

I've got a 2019 Intel iMac running Sequoia 15.4.1 and Xcode 16.3. Every time I try to view a storyboard Xcode locks up and beachballs on me. It takes minutes to load the file. When I force-quit Xcode, the report that shows up has this as the reason: Processes reached dispatch thread soft limit (64): launchd_sim [96305] [unique pid 194673], launchd_sim [96260] [unique pid 194628] Deadlock: AppleSpell [1494] thread 0x1df0c4 DispatchQueue 313 -> AppleSpell [1494] thread 0x1df0c4 DispatchQueue 313 Deadlock: AppleSpell [1494] thread 0x1df114 DispatchQueue 86 -> AppleSpell [1494] thread 0x1df114 DispatchQueue 86 Blocked by Deadlock: 1 task - AppleSpell [1494] I'm wondering, why is AppleSpell trying to spell-check a plist file? Is there any way to tell AppleSpell to ignore a file?

I've updated to Sequoia 15.4 and Xcode 16.3 on my Intel iMac 2019 and now everything Xcode does results in a spinning rainbow. Open a window? Spin. Look up documentation? Spin. Compile the app? Well that doesn't spin, but simple things like compiling a storyboard now takes over 5 minutes. Every compile needs to redo compiling Clang modules over and over again. And compiling the project at times just stalls out. It's been bad for a while but now with these versions it's gotten even worse. Is Apple just saying give up on Intel and get an M-series Mac just to develop with? On my Intel Mac the project takes over 19 minutes to compile. The main storyboard takes almost 7 minutes alone! It didn't take this long with Xcode 16.2. The other storyboards are showing times of over 4 minutes as well, a vast increase. A swift file with two functions, neither of which is over 10 lines, takes 87 seconds? It seems like everything involving swift code is now taking much much longer to compile. And don't even get me started on debugging. 90% of the time I can't find symbols, and clicking on a variable leads to spinning. Entering anything into the debugger window results in a warning about not being able to show the value and now I have to figure out how to cast the return value to what it should be? Why? All of this used to work, and now it doesn't. Or does, but not reliably. So after all this, I went and configured an M3 Mac mini I had dedicated for other purposes for Xcode. Took a while as the mini is very limited on space, and Xcode was too big. After getting it set up, certificates transferred, account set up etc, I copied the app's files and hit build. It took 47 seconds.

I'm trying to compile my iPad app with Xcode 16.2 and I'm consistently getting this error message: couldn't find compile unit for the macro table with offset = 0x0 This is happening at the GenerateDSymFile step. I've tried changing the debug format from Dwarf with Dsym to Dwarf and then back again, as I've read there was a problem with generating the dsyms. But the problem persists. I've tried searching for this error and found nothing online, so apparently I'm the only one! How strange. Are there any settings or flags I can change to try to get more information about what's going wrong?

Ok, weird one here. I have a widgetkit watch extension that I'm transitioning to. All code compiles clean, but when I go to install I get an error that it can't be installed on the watch because the extension does not define either a NSExtensionMainStoryboard or an NSExtensionPrincipalClass key. I don't have a storyboard for the extension as it's for the complications, so I added a principal class key. Now it won't install with the error that it defines a principal class which is not allowed for the extension point com.apple.widgetkit-extension. Huh. Well, ok, um... I guess I'll rip it out and stay with the deprecated clock kit complications, since they at least install. But this is very frustrating, and makes me think Apple wants us to go insane!

I've upgraded to Xcode 14 and the suggested changes to the project included making the WatchKit app and the extension be a single target. Once I did that, my complications and my old extension code can't find the objective-c objects that I had included via a bridging header. I've gone looking in the watch app settings and there is no option for setting the bridging header. None that I can find, I should say. There is no Swift Compiler section at all, and I can't seem to add a user-defined setting either. Now the app won't compile. If I restore from time machine and try again, then I can't install the app because Xcode tells me that an extensionless WatchKit app has an extension, which of course it does! So how do I add the bridging header to the WatchKit app?

I tried to build my app with Xcode 15 and as part of that I changed the current project version and marketing version in the main app, but when I went to the various intent and watch extensions, the option to change the versions weren't there. I thought "hmm maybe Apple has gotten smart and just made those follow the main app" but I was wrong. The settings are still there but there is no UI to change them, and compiling now shows warnings about mismatched versions. When I go into Build Settings and look for Versions, I can find the wrong values and change them there, but this is very laborious. Deleting the settings sets them to the default project versions, but there is no UI to set these either so nothing is changed and warnings still appear. So for now I'm stuck with manually going to each build setting page and changing the versions there. Sigh. I think I'll file a bug report, this can't be right.

I have a watch complication that used to work just fine and now all of a sudden in my latest build it's showing only dashes. The watch app is there, if I tap on the complication then the watch app opens correctly, if I edit the watch face and select the complication I can see my placeholder (and it's fine) but when I select that complication, the sample watch face shows dashes. The only major change I've made is to make the watch app a single-target without an extension delegate as per Apple's recommended settings. I don't think this is the problem as the simulator shows the complication. It's only on the Watch Series 4 that I'm testing on that I can't see my complication. It was working only last week and I have not touched the complication code at all, so I'm stumped as to what's wrong. I can't find any help on line, apparently no one has ever seen the complication just have dashes. When I debug the watch app and ask for how many complications there are, it comes back with zero even though I've put them on the watch face. It seems like watchOS9 is just not respecting the complication any longer but I can't figure out why. Please note that I'm not using WidgetKit complications as the corner complication doesn't flow the text in an arc like ClockKit does, so I'm still using the old complications. But none of the code is getting called as none of my breakpoints are firing. I've rebooted the watch about 10 times and the problem persists. Any ideas why all of a sudden this has fallen over and gone boom?

Hello! If you see this post on stackoverflow, it's because I posted in both places. I have an app that I'm doing receipt validation via the validateReceipt endpoint (for iOS15) and the new StoreKit2 AppTransaction for iOS16. All is well until... A user reported that the app keeps telling him that there is no app receipt to validate and wants him to sign in and get a new receipt. Trouble is, his iPad is under device management from Mosyle and he doesn't have the account ID or password to sign in with. Well duh, of course not, that's handled by IT. My understanding is that the receipt is tied to the user account and the device that the app is on, so if the app is being distributed from a server then the receipt won't match the device, or possibly isn't even part of the distribution. I'm unclear on this, as all I'm getting is an alert about the receipt. I'm adding more code to detect and report on what might be happening inside the app, but in the meanwhile I have to figure out what to do to get rid of the warning prompt. My questions, after having read volumes of unhelpful information about MDM's, are simple. Is there a way to detect inside the app if the app was installed via an MDM? Can I tell from inside the app if the device is registered in an MDM? And how can I tell that the app is authorized to run on the device if the receipt validation methods aren't, well, valid? I have tried multiple combinations of search terms yet nowhere can I find out how to detect a valid MDM configuration and thus not look at the receipt. It seems the answer is either that developers aren't checking their receipt or that the solution is so blazingly simple that I'm just not seeing it.

I have a weird problem with App Review. My iPad app, which has been in the store for years and regularly updated, needs another update to address a corrupt database issue. I'm on Xcode 14.0.1 and Mac OS 12.6. App compiles fine, nothing is wrong. But when I submitted it, App Review rejected it because of internal references to iPad OS 16. These references apparently come from Xcode 14.0.1. I can't remove them, it's Apple's code! I don't include any objects, functions, or references to iPad OS 16 in my code. I target iPad OS 14.0 and above. I don't even have the beta installed on any device, yet because Xcode has it, my update is rejected Am I supposed to install an older version of Xcode just for this one app? Why would Apple release developer software that can't be used, and call it the release version? And why is it that small developers like me always seem to get the short end of the stick when Apple starts marching around wrecking things? This situation is ridiculous and I'm frustrated.