I see from the tooltip in the last screenshot that your documents are in the cloud. You said you "moved to new computer". Did the system have time to sync all your documents? Did you try deleting the derived data folder, then archiving and distributing your app again?

all the documentation for development of applications for iOS, watchOS, iPadOS, macOS, visionOS is available without a paid developer account. To develop accessories under the MFi program, you need an MFi program membership. https://mfi.apple.com Is there anything specific you cannot find?

Presumably you are developing an app that runs on something other than a Mac? Connect the destination phone or iPad to the development Mac with a USB cable. The iPad/iPhone will ask if you want to trust the computer. Xcode will take a little while to make the iPad/iPhone ready for debugging. You can monitor its progress using Xcode's Window/Devices and Simulators menu. I don't think there's any control over how Xcode begins debugging - it uses USB if there's a connection, WiFi otherwise. If I break the USB connection mid-session, Xcode does not fail over to WiFi automatically.

My first question is "why?" If you're only changing the vid/pid to make the product appear different to anyone else's which is based on a CP2102, do you really need to? Can you figure out whether it is yours by probing the serial interface? Could you just change the vendor and product strings, instead of the IDs? How much user confusion is likely to arise if you just stick with Silicon Lab's vid/pid? All of this dext scaffolding is quite painful to get right. The user is burdened with approval of the dext, but if you didn't change the vid/pid of the CP2102, they would not be, because the Apple dext is pre-approved. I don't know if you can use the recommended approach here, of subclassing from a known DriverKit class, but overriding nothing. This is because AppleUSBSLCOM is specific to the Silicon Labs CP2102, its interface isn't in the DriverKit headers. You can't simply inherit from IOUserUSBSerial, because that driver doesn't know about CP2102, and I don't think you can inherit from AppleUSBSLCOM, because you have no header file for it. I'd try two things: go to /System/Library/DriverExtensions/com.apple.DriverKit-AppleUSBSLCOM.dext and copy the DriverKit-AppleUSBSLCOM-CP2102 IOKitPersonality from it, change the idProduct and idVendor and put that modified dictionary into your driver's plist. Your personality is now referring to an executable which isn't present in your bundle, I don't know if that will work. You may need to ensure that your dext contains some executable code, but this personality won't refer to it. Your code should already generate a do-nothing dext. ensure that your app actually tries to activate your extension using what does systemextensionsctl list tell you? I use log collect --last 20 immediately after activation to give me a workable log archive that isn't too huge and isn't constantly changing where I can read messages which my be pertinent to my dext. I don't use systemextensionsctl developer on any more. Its laughingly poorly documented - what is developer mode, for example (FB7656761) ? As for entitlements, your hosting app needs the System Extension entitlement. Your driver needs DriverKit (a boolean YES), DriverKit USB transport (a dictionary containing an array of idVendors, usually just one), and DriverKit serial family

those NSValue things are special. They are containers, with their own accessors for their contents. for (NSValue *obj in dev.activeFormat.supportedMaxPhotoDimensions) { CMVideoDimensions vd = obj.CMVideoDimensionsValue; NSString *s = [NSString stringWithFormat:@"res=%d:%d", vd.width, vd.height]; //print that string }

@Pokka your screen shot is from "Color LCD", which is what Apple calls the built-in display on their laptop. By default, this uses the P3 color space. If you go to Settings/Displays, select the built-in display and change its Preset to "Internet & Web (sRGB)", the Digital Color Meter should show you the values you expect. Alternatively, you can create the color in the P3 color space: let darkorange = Color(.displayP3, red: 213/255, green: 131/255, blue: 120/255) The default display gamut is sRGB, which isn't as wide as P3. So when you create your dark orange in sRGB, then display it in P3, it isn't as colorful as you'd expect.

I see it has been a week and no-one has answered. I've never used Swift Charts, but I'll take a stab at this. You're feeding four channels of data at 2400 samples/sec into an ever-growing array of structs. Each sample struct (VoltagePerTime) contains a string with the channel name, but the channel name probably doesn't change from one sample to the next sample in a given channel, right? So why not infer the channel name from the array you put the sample into. Then you don't store a bunch of identical strings in your sample array. Are the samples arriving at constant intervals? If so, the time can be inferred from the position in the array, so you don't need to store the time. At most, you would need to store the start time of each sample set. I assume the samples arrive in strictly monotonic time order. However, your ChartView filter closure examines every sample you have collected, to see if it falls within the time you wish to graph. As your sample set grows, simply fetching the samples in your graph window takes longer and longer. You should consider using a smarter algorithm to select the data that you pass to the graph, using what you know in advance about the data. Store as little as possible, prefer numbers to strings. Also, you have @Published every array. But if your graph is currently viewing the first 2 seconds of data, while you collect the tenth second, nothing is going to change on screen, but you're nevertheless asking the ChartView's body property to be re-evaluated. If you leave your app running for long enough, you're going to run out of memory, so you should consider implementing some kind of persistent buffer for your data, or a circular in-memory buffer, or both. There are further optimizations you could consider, but these suggestions may be enough to give you acceptable performance so that you can get on with the rest of the project.

Is this a Bluetooth, or a Bluetooth Low Energy device? Is it yours (do you own the firmware, and know what it does)? Or is it a device from a third party that you would like to use? The easiest type of device to support is BLE. Have you looked here: https://developer.apple.com/bluetooth/ ? If you've never done this before, start with the Heart Rate Monitor app and use an off-the-shelf heart rate monitor. The Heart Rate Monitor profile is a published standard profile. If you're comfortable with it, you can also use a low-cost BLE development kit to make your own BLE device, with any profile you like, using chips from TI, Maxim IC, Silicon Labs, Nordic, Dialog etc

you can enable the undefined behavior sanitizer in the Scheme settings under Diagnostics. This produces this warning for me, even for debug builds: runtime error: shift exponent 64 is too large for 32-bit type 'int' SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior There's another, separate build setting, CLANG_UNDEFINED_BEHAVIOR_SANITIZER_INTEGER, which did not help here. This forum isn't a place to report bugs - use Feedback Assistant for that. Undefined behavior really is undefined, you just got away with it before.

please provide more detail about the camera that doesn't work. Is it yours (do you own the firmware?) Is it supported on the Mac by the vendor? Have you inspected its USB descriptors?

maybe this is helpful? https://llvm.org/docs/CommandGuide/llvm-as.html

use a second Mac with Apple System Configurator 2 to restore or recover the OS. https://support.apple.com/guide/apple-configurator-mac/intro-to-apple-configurator-cadf1802aed/2.17/mac/14.0

Further progress here. Following the instructions in TN3125, I find that the certificate inside the .mobileprovision file is expired after all! The steps were: remove the cms (Cryptographic Message Syntax wrapper) security cms -D -i <path-to-app>/embedded.provisionprofile -o badapp-payload.plist eyeball the badapp-payload.plist file, verifying that it includes a DeveloperCertificates section extract the first certificate plutil -extract DeveloperCertificates.0 raw -o - badapp-payload.plist | base64 -D > cert0.cer inspect the certificate certtool d cert0.cer which says Not After : 21:10:25 Sep 21, 2023 so, big oops on our part. Hopefully someone aside from myself can learn something from this, I'll post if the problems are all fixed by using a valid certificate.

I tried the new tool, syspolicy_check. It said (rightly) that we'd forgotten to staple the notarization. My Mac has Internet access to that won't make any difference, but I stapled it anyway. The results didn't change - the app won't launch.

@eskimo thanks for the reply codesign --display --entitlements does show a com.apple.application-identifier is present, it is the same for both apps - the bundleID prefixed by our teamID. security cms -D on the embedded.provisionprofile shows the same result for both apps, including the same com.apple.application-identifier value in the Entitlements section. The working and non-working app both refer to the same certificate, with the same serial number, hash and expiration date. The profile for both the working and non-working app expires Sep 23, 2040 at 9:36:53 AM PDT The The plists differ a little, because the two apps were built on different Macs with different toolchains. BuildMachineOSBuild good 22A400, bad 22G90 DTPlatformBuild, good 14A309, bad <empty string> DTPlatformVersion, good 12.3, bad 13.3 DTSDKBuild good 21E226, bad 22E245 DTSDKName good macosx12.3, bad macosx13.3 DTXcode good 1400 bad 1430 DTXcodeBuild good 14A309, bad 14E222b I ran spctl --assess -vvv on the bad app, which said accepted I edited this post, previously I said spctl claimed the bundle format was unrecognized. That was my error - I passed it a path to the app which has spaces in its name with un-escaped spaces. Instead of it telling you that the path doesn't exist, spctl says it is broken. I don't know whether to believe that, because the system log tells me something else. Also, the bundles are almost identical. The "good" app has an additional profile, "embedded.mobileprovision". Which one does the OS use, and why is there an embedded.mobileprovision file in a macOS app? I'll have another look at those links you cited, thanks