You're using a third-party tool and you're new to iOS development, so your way ahead is likely to be a little rocky. I suggest you start by examining the built app bundle on the Mac, see if its plist, its resources and the error messages from Xcode are self-consistent. The Info.plist you posted here doesn't look like an Info.plist in an iOS app bundle - your file is plain text, Info.plist files are xml. Then, on the Mac, in Xcode, build an iOS app from the template and try to send that to Test Flight. Understand the requirements for icons files and how they are fulfilled. Compare what is built by Xcode, the first-party tool, with what your tool is building.

Feedback Assistant is the place to report bugs.

I don't know. I tried your example, and with and without the HStack (and its accompanying braces, of course), I get the same result, the one you expect. Xcode 16.1, macOS 14.7.1, built for macOS and iOS simulator.

On my (real) M1 Pro MacBook Pro with macOS 14.7.1, it looks like this. What machine are you running your VM on?

this forum is for questions about software development. Your question would be better suited for https://discussions.apple.com/welcome option-W produces upper-case sigma (Σ). There doesn't seem to be a direct keyboard entry for lower-case sigma (σ). Type "language" into search field of System Settings, look for "Language input methods", select it, and turn on "Show input menu in menu bar". If you have only one input method, you'll still have access to the Keyboard Viewer and Character Viewer from there. You could also try enabling the Greek keyboard. On a US keyboard, sigma is on the key labelled 'S'. You can switch between keyboard input languages using the icon in the menu bar, or ctrl-space bar.

I think you can just make a codeless kext with a plist like this one: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>CFBundleDevelopmentRegion</key> <string>English</string> <key>CFBundleIconFile</key> <string></string> <key>CFBundleIdentifier</key> <string>com.apple.driver.AppleUSBHub1009</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundleGetInfoString</key> <string>1.0, Copyright © 2011 Apple Inc. All Rights Reserved.</string> <key>CFBundlePackageType</key> <string>KEXT</string> <key>CFBundleShortVersionString</key> <string>1.0.0</string> <key>CFBundleSignature</key> <string>????</string> <key>CFBundleVersion</key> <string>1.0.0</string> <key>IOKitPersonalities</key> <dict> <key>Hub1009</key> <dict> <key>CFBundleIdentifier</key> <string>com.apple.driver.AppleUSBHostMergeProperties</string> <key>IOClass</key> <string>AppleUSBHostMergeProperties</string> <key>IOProviderClass</key> <string>IOUSBHostDevice</string> <key>idProduct</key> <real>1544</real> <key>idVendor</key> <integer>1234</integer> <key>IOProviderMergeProperties</key> <dict> <key>kUSBWakePortCurrentLimit</key> <integer>1100</integer> <key>kUSBSleepPortCurrentLimit</key> <integer>1100</integer> <key>kUSBHubPowerSupply</key> <integer>1300</integer> </dict> </dict> </dict> <key>OSBundleLibraries</key> <dict> <key>com.apple.iokit.IOUSBHostFamily</key> <string>1.01</string> <key>com.apple.kpi.iokit</key> <string>10.4.2</string> </dict> <key>OSBundleRequired</key> <string>Root</string> </dict> </plist> I added a tiny amount of code. My driver is a subclass of IOService, and overrides Start(), just so I can see it logging. I think, but have not checked, that the AppleUSBHostMergeProperties driver returns an error from its Start (but first merges the properties). The downside of course is that dexts are not loaded until after boot time, so your dext usually has no effect because the system has already loaded a driver for the hub by the time your dext is available. If you plug the hub in after boot time, the codeless dext will be instantiated. (FB12048885)

maybe (and I haven't tried this, we just put up with the hiccups) xcodebuild -checkFirstLaunchStatus and if you're okay with agreeing without reading: xcodebuild -license which are documented at the end of xcodebuild's man page.

I don't remember it being complicated at all. Using the Mac is no different than using an Intel Mac, but often noticeably faster. Building for Apple Silicon is completely automatic for new projects. For existing ones you may have to change one Build Setting (Architectures). You can build for Apple Silicon on Intel, just as you can build for Intel on Apple Silicon, so really nothing changes here. If you're asking about changes required to software source to support Apple Silicon, they're detailed here: https://developer.apple.com/documentation/apple-silicon/porting-your-macos-apps-to-apple-silicon

softwareupdate --list-full-installers softwareupdate --help You can't install software older than the machine you're installing on. I keep full installers for the latest major revisions on an external disk. Hope this helps.

You could post the build log here, that would tell us some more. But there's (almost) nothing wrong with your code itself. I copied, pasted it, compiled and ran it. You probably configured your project wrongly (don't worry, there are LOT of options!) In Xcode, choose New Project. Choose the macOS Command-line Tool template. Give the project a name, choose C as the language. Once you save it, you'll get an Xcode project containing a command-line tool target which will print "hello, world" to stdout when run. You can select all the code you posted here, paste it in to main.c (replacing everything in the template code). Xcode will flag some errors due to formatting which are easy to correct - for example each #include line needs to be on a separate line. You'll end up with one warning about int main() being deprecated. You can fix that by changing int main () { to int main (void) { or int main(int argc, char ** argv) { after that, your program should build and run. If it doesn't, read the detailed build log, and if you don't understand it, post it here.

in order to post here, you're a registered developer. If you click on the Account tab at the top of this page, then on the Membership Details icon, you'll see the name of the Account Owner and you can send them an email. Of course, that won't work if you're logged in as an individual rather than a member of the organization's team. If your company has lost those details, you can try the Contact Us link at the bottom of this page and explain your situation.

another approach is to paste the offending code into some well-known llm, and ask it "what is wrong with this SwiftUI code". A predictive text model is quite good at spotting this kind of error, and suggesting a correction.

You haven't posted enough context. If you click on the Report navigator icon (the rightmost icon at the top of the left column in Xcode, which looks like a hierarchical list), you can see the full build log, which should help you to fix errors like these. With what you've posted, we can't see the name of the first missing file. The second missing file may be missing because the first is missing, and that in turn may be due to something reported only as a warning in the detailed build log.

if you scroll down to the bottom of this page, you'll see lot of links. Under the Support section there is a Contact Us section, use that to submit a support request to developer services. This forum is primarily for developers to help other developers with programming questions. It isn't an official Apple support channel, and it is public.

I can tell you my experience with a Camera extension, and with a USBDriverKit extension. I believe the requirement that the kext's bundle ID begin with the bundleID of the hosting app is for iOS/iPadOS only. There isn't such a restriction for the dexts that I know about (but networking or security extensions might have different rules). That said, I see that I actually obey that rule with my projects, and it doesn't do any harm. Your dext has a managed entitlement for PCI. Your Account Owner has to make a profile for that on the developer portal - an Admin can't (but won't see a helpful error message, last time I tried as an Admin). You can leave all the Xcode settings that are working for development as they are. Try not to fiddle with Info.plist files or Build Settings directly if there is a way to set the same settings using the Info tab for your target, or the General tab, or the Signing and Capabilities tab, because those feed into the Build Settings. in my main app and dext targets, the Provisioning Profile is "Xcode managed profile" and the Signing Certificate is a Development one. That's fine, it is all going to re-signed for distribution. When you want to build for distribution from Xcode, archive your build. choose Distribute choose the Custom distribution method select Direct Distribution select the Export destination use the Manually Manage Signing option at this point, you'll be able to choose a Developer ID Application certificate, and the appropriate profiles for you app and its extension. If you're doing all this from a script, you have to figure out what the right commands are which correspond to the steps in the dialogs. Good Luck! I can't take you any further with this, because I gladly ceded signing and notarizing tasks to our DevOps team, so I don't have the signing certificates with the private keys on my Mac. AFAIR, I selected "None" for my app's Profile, it doesn't need anything special, while the driver has managed entitlements and I do need to set its profile explicitly. After a successful signing step here, you can use notarytool to notarize the app, and attach a ticket to it. There's a post from Kevin Elliot here about this https://forums.developer.apple.com/forums/thread/751490?answerId=787624022.