Hans♫

Thank you, but it seems to be a solution similar to the one I refer to? I prefer not to have a custom edition of each components placed on the Listbox. However, I also realize that both solutions relies on that scrolling actually does work when tapping a control, but it does not work for me. As soon as Hittest=true for the control on the listbox, then it does not scroll at all when I touch that control.

It looks like the Oboe library is the way to go for low-level audio input/output on Android. But it's a C++ library, so it will require writing a wrapper to flatten it. Do you know anyone using Oboe in Delphi, that might have written a full or partial wrapper? PS. I am usually a little afraid to share my own wrappers on various platforms because they are usually only partially completed and I fear that I also have to provide support for it, and instruct how to use it 😉. However, anything you have would be a great help 🙂

I have used SDKtransform for years (executed through "SDK Transform Assistant") to implement the iOS and OSX frameworks that are not included with Delphi. However, an increasing number of classes fail to be converted and are not included in the output .pas header file. Right now I need to convert AVAudioEngine from AVFoundation in MacOS 11 (Big Sur), but SDKtransform fails with a lot of these lines added to the log: "WARN: cannot add ObjCInterface AVAudioEngine - base class unknown" Could this be due to the way it is defined (as an interface)? API_AVAILABLE(macos(10.10), ios(8.0), watchos(2.0), tvos(9.0)) @interface AVAudioEngine : NSObject { @private void *_impl; } - (instancetype)init; - (void)attachNode:(AVAudioNode *)node; - (void)detachNode:(AVAudioNode *)node; ... @property (readonly, nonatomic) BOOL isInManualRenderingMode API_AVAILABLE(macos(10.13), ios(11.0), watchos(4.0), tvos(11.0)); ... @end // AVAudioEngine How do I autoconvert this type of header definitions? PS. This is a copy of my post on StackOverflow.

I have not seen any yet. Where do you experience problems? Maybe. There is a chance that you could implement debugging without offering arm as a target, but I suppose it would rely on the Rosetta 2 emulator, if that implements mapping of instructions and memory for debugging purpose. With the limited development ressources that Embarcadero can put into it, we are probably not seeing debugging support for the M1 until they make a full support of the M1 ARM target.

No it still doesn't work, and I realize I forgot to create an issue about it. Now it is there: https://quality.embarcadero.com/browse/RSP-32362

I have no performance numbers, but it "feels" faster. Apps starts faster and feels more responsive, but maybe it is also related to being a new and fresh installation of MacOS, compared to a 3 years old Mac Mini with Intel.

I have a Mac Mini with M1 CPU. You can run PAServer on it and deploy Delphi MacOS apps on it, but you cannot debug. So as long as you choose "Run without debugging", then it works fine. See also this post:

The roadmap refers to ARM M1 as a target platform. What I am referring to is to be able to debug the Intel target on an ARM M1 CPU. I can deploy and run from Delphi on the M1 CPU, but I cannot debug. It might not be possible to use the CPU view in Delphi, as it would have to work through the Rosetta 2 converter, but limited debug facilities would suffer, e.g. Breakpoints and variable inspection.

Now I had time to investigate it a bit further. Looks like debug mode does NOT work on the new M1 CPU. I can run a MacOS application from Delphi on the M1 Mac, without debugging, but when I run in debug mode I get the error: "unable to create process 'debug kernel timeout'". The same application runs fine in Debug mode when using an Intel Mac having the same versions of MacOS (Big Sur) and XCode. Before I create an issue on on Quality Portal. Are there any suggestions for things I should try first? - or extra information I can retrieve and include in the issue?

The FMX.InAppPurchase component already implements in-app purchase for iOS, and since OSX uses the same StoreKit library, I simply added an OSX copy of the iOS implementation and adjusted it to "work" on OSX. It works as far as it compiles and runs, and I can call "QueryProducts", which also initiates a Delegate callback. Once in a while I can even successfully read the product details from App Store that I receive in the callback, but most of the time the callback fails with an AV. It seems to be random where it fails. If I restart paserver before each run I can increase the chance that it works, but except from that I did not find any correlation between changes I have made and a successful request. The testprogram works fine on iOS. On OSX I have tried to target both Mojave and Cataline, and both 32 bit and 64 bit editions. They all fail. As the OSX code is the same as the iOS code, I guess that the problems are related to differences between the iOS and the OSX target in the Objective-C handling and wrapping. Any ideas what could be wrong, or what I should try? (or maybesomeone with more knowledge about Objective-C wrapping and the inner workings of Delphi could help me with this?) Below are some extracts from the code in my new unit "FMX.InAppPurchase.Mac". My test program creates TiOSInAppPurchaseService and call QueryProducts. It works without errors, and a few seconds later the TiOSProductsRequestDelegate.productsRequest callback is called. From here random AV's happens. Usually it fails on the first line FIAPService.FProductList.Clear, and sometimes it fails earlier in "DispatchToDelphi" or later in one of the following lines. TIAPProductList = class(TList<TProduct>) end; procedure TiOSInAppPurchaseService.QueryProducts(const ProductIDs: TStrings); var ProductIDsArray: NSMutableArray; ProductIDsSet: NSSet; ProductID: string; begin ProductIDsArray := TNSMutableArray.Create; for ProductID in ProductIDs do ProductIDsArray.addObject(PStrToNSStr(ProductID)); ProductIDsSet := TNSSet.Wrap(TNSSet.OCClass.setWithArray(ProductIDsArray)); FProductsRequest := TSKProductsRequest.Wrap(TSKProductsRequest.Alloc.initWithProductIdentifiers(ProductIDsSet)); ... FProductsRequest.setDelegate((FProductsRequestDelegate as ILocalObject).GetObjectID); FProductsRequest.start; end; constructor TiOSInAppPurchaseService.Create; begin ... FProductsRequestDelegate := TiOSProductsRequestDelegate.Create(Self); FProductList := TIAPProductList.Create; end; constructor TiOSProductsRequestDelegate.Create(const IAPService: TiOSInAppPurchaseService); begin inherited Create; FIAPService := IAPService; end; procedure TiOSProductsRequestDelegate.productsRequest(request: SKProductsRequest; didReceiveResponse: SKProductsResponse); begin FIAPService.FProductList.Clear; ... end;

I have attached the FMX.InAppPurchase.Mac.pas that we use so it is easy to use for others. All you need is to add it to your project and also add a modified version of FMX.InAppPurchase.pas where you include the file (just search for FMX.InAppPurchase.IOS, and see how that file is added, and do the same with the FMX edition) FMX.InAppPurchase.zip

We use InApp purchase on MacOS and it works fine. Sorry for not updating this thread. I worked with David directly to solve the problem in our code, but I think David has implemented his own solution in his Kastri framework: https://github.com/DelphiWorlds/Kastri

You'll probably need to do a lot of tweaking and manual work to create an AU with Delphi. The recommendation from Apple is to inherit from the AU base classes: "The quickest way, the one endorsed by Apple, and the one described in this document, is to subclass the appropriate C++ superclasses of the freely-downloadable Core Audio SDK." https://developer.apple.com/library/archive/documentation/MusicAudio/Conceptual/AudioUnitProgrammingGuide/Introduction/Introduction.html When I have needed to access C++ objects in Delphi, I have flattened them, but I don't know if this can be done everywhere in this situation. Someone else can probably tell you more about how you can handle that.

EarMaster is a unique and highly praised app made in Delphi for Windows, MacOS and iOS. We are looking for a unique profile, and therefore I also share the job internationally. For the right person, this will be a dream job that might make you consider to relocate to Denmark! This job is at our office in Aarhus, Denmark, and remote work is not an option - don't waste your time to ask if we are sure, or if we have other jobs for remote workers 😉 The job add is in Danish, but it is not an absolute requirement that you speak Danish if you have strong English skills. The Google translated job add can be accessed here: https://www.it-jobbank.dk/jobannonce/362739/musikalsk-lead-udvikler-til-verdenskendt-musikteori-app You can find more information about the app at our Website: https://www.earmaster.com Youtube channel: https://www.youtube.com/user/eartraining and for a more technical insight, here is the video we made 4 years ago when our iPad app became the Embarcadero "Cool App Winner":

Good sense of rhythm is always a plus 😉

I made Delphi headers for the Canon SDK about 20 years ago. It allowed me to connect to the camera, show live preview, zoom, take pictures and download the pictures into my software. Don't know if the headers are of any use with the current SDK, but if you want to try, you can get it. No support included 😉

Sorry I didn't see that. I have sent a PM with those headers too. However, there are a lot of details to figure out before you can achieve what you want. Having the headers is just a small part of it. With a lot of Googling, reading and persistence - eventually you will get through 😉 Keep up the spirit!

If have sent a PM with the file, but you are far from done having this file. The best advice is to find code in Objective-C that does what you want, and then convert it to Delphi - which might include a few headaches.

All the AudioQueue... functions are in iOSapi.AudioToolbox. Do you know how to convert the SDK headers your self? - or else I can send you my version of the file.

We have developed a low-level audio input solution for Windows, MacOS and iOS. It allows us to process audio immediately when each buffer is filled and delivered to our code. I cannot share my code here, but here are some hints of the API functions we use on iOS: AudioQueueNewInput AudioQueueAllocateBuffer AudioQueueEnqueueBuffer AudioQueueStart AudioQueueStop

I suppose the problem you have is the one described here: https://community.idera.com/developer-tools/platforms/f/macos-platform/70850/macbook-pro-high-sierra-gui-is-zoomed

Our iOS app made with Delphi showed an alarming increase of crashes with the latest update, that was built with Delphi 10.3. So I made this graph in "App Store Connect" that shows a similar increase of crashes when upgrading to Delphi 10.2.2. This is a bit scary... where will it end... Graph shows crashes per week: The vertical gray lines shows when we released a new update of our app. The number of sessions per week is almost the same during the whole period, so that does not influence the graph. Unfortunately I don't remember what version of Delphi I was using before the 10.2.2 upgrade.

Thanks, I got that email too, but obviously missed the part about the storyboard 🙂

I don't know when (or if) Apple will make it a requirement to use the Storyboard, but so far you can still use the old way that Delphi supports right now. We are not using the storyboard solution in our app, and that is still accepted by Apple. Its only one week ago we uploaded the last update.

Is there a confusion between "App Store" and "Mac App Store" somewhere? The error message contains both "Mobile" and "App Store", which refers to iOS, not MacOS. Our App is on Mac App Store now, though we use our own shell scripts to sign and build the final application package.