Rollo62

Would that mean that when NOT using the new AppBundle feature, and the new Apps will be 64-Bit in coming Rx10.3.x, then these 64-Bit APK won't run on those devices ? Or will the coming Rx10.3.x version APK contain both, 32- and 64-Bit code ? That would mean "AppBundle" is a must to support all devices with such 32-on-64 Bit OS, is that correct ?

I don't know if Aerserve is still active and running with Rio, never checked thant. Maybe somebody has more info about this ?

What exactly are you looking for ? For FMX on Mobile, there is TBannerAd, is this what you are looking for ?

I have many copies of VM, if I understand your issue right, mainly for backup and "snapshots" for updates etc. No problem to start a newly copied VM, or to install into older, clean VM, just tell VmWare "I have moved it" and it should be fine. ! But you should avoid to have multiple VM running at the same time.

When you wont get ready in time with your XCode 11 installation and iOS 13.2 preparation of the phone, just watch this. That happens to me right now, and I just decide to choose the 15 minutes wait version, since the other options didn't help I should clarify that this is another Apple issue (not Delphi), as there were too many issues in iOS 13 for the last weeks. Would like to get on going soon. Edit: Yes it seems IOS 13.2 was a Beta version, but it was installing with no special note. Of coarse now XCode 11.1 cannot get development access to this, and I don't want to install the next XCode 11.1 beta really. Nevertheless, I will have to forget my iPhone test device for a while, and check further with another one. Unbelievable that my phone could make a Beta update, without presenting the stable version as normally, or any question before. So my advice: Never do updates on iOS beta versions, or you're in trouble.

Just to let you know: About 4 days ago the official XCode 11.2 came out, which I just installed and tested. Now iOS 13.2 works fine again, XCode can deploy the debug image, and I can debug and test as usual. The problem was that my iPhone was installing a beta version (13.2), which was only supported by a beta XCode 11.2 at that time, without any notice. Maybe the reason was that Apple released the IOS 13.2 (final) BEFORE the according XCode 11.2 was released. During that time gap this will break debugging, affect app-store approvals (if I would have installed an XCode beta release), and so on. Various headaches, so I will check how I could better prevent unwanted updates in the future.

Good that you solved your issue with OSM. However, its strange that your apps crash on most of these phones. I have not all of your phones in the list, but maybe 40-50%, OK the MapView is not the main purpose in my apps. so its probably not stretched to the max. I would expect anything like > Galaxy 7 should make not such issues with GPU at all, when following the advices above. Somethimes the issues may come from a total different side, are you sure you had a valid GoogleMaps Token and defined correct in the dashboard ? Have you tried a new, blank app, with MapView only ?

Probably yes, its NOT an Delphi issue. But I cannot get even close to this, since XCode doesn't want to speak with the iPhone at all. It cannot even fix anything or build and compile an empty XCode app. Maybe one way would be to install older debug images on the phone, but I still have not figured out how that can be done in 100% safe and secure way. No time at the moment to fumble around with iOS, I still have to test Android 64 compatibility.

You were asking for options, and if the signatures are well defined and limited thats a possible option too. So that meant you could use overloads for the most common ones. E.g. I try use mostly compatible signatures, also for different domains in my projects. The array of const can catch then all the rest.

CrossPlatform = FMX TMS OSMaps

You could also use several overloaded Log methods, with 1, 2, 3, ... strings.

Hi there, usually I don't care much about iOS versions, I would expect that those customers have the latest stuff always. But I was facing the issue that an older iPHone 5S (iOS 10.3.4) cannot tested via TestFlight. I see a message, similar to this https://stackoverflow.com/questions/33900295/app-not-compatible-on-iphone-4s-and-5-in-testflight Of coarse I may use features that are probably not available in older IOS, but I'm asking myself in general what strategy would fit best, to keep most apps as compatible as possible. I don't really know if iOS 10 is still supported, but the platform status says so, that is will be down to iOS 10.3 (never tested this). Its not easy to find out which features are depreceated or changed in each version, or is there maybe a good history of versions in the web ? I have never seen any for iOS. Currently I'm trying to encapsule simple features, as best as possible, so that I can test and enable/disable them separately (like notification, tts, sensors, location, etc..). What I did not incuded yet is a kind of "version control" for each feature, I think about e.g. certain features may have varying permisson models and behaviours, but that could be still acceptable for basic functionality of the app. Each feature could behave slightly different within different versions, but the app wouldn't crash right away, instead notifies gracefully. Probably this would be a little too difficult for abstraction, but I hope that breaking changes doesn't occur too often. I think XCode does a very good job in helping the developer in these cases, and to fix issues automatically, would like to have such XCode knowledgebase in my code too . If there are some interesting links about such abstraction, I would be happy to get some feedback.

I wanted to build a "system" or "pattern" that better could encapsulate such changes from the interface side. Of coarse the internal implementations may look totally different, and TOSVersion would help much. My goal is that from the interface side all this complexity is hidden. Not sure howto hide such complexits best. Personally I like the CanUse, DoUse, TryUse patterns, but they also need some kind of conditions when not necessary. Probably there are better concepts out there. I'm also not sure if enhancing the FMX.Platform system is a good idea, since this is the domain of Embarcadero, but I think doing so would keep the same pattern also for my own interfaces. Another possibility is simply "fixing" broken classes, to get the desired behaviour, e.g. by interposer classes. There are also people who like to completely replace the existing interfaces, by some own, well controlled interfaces, like maybe the TMS FNC did (I don'T really know this, but I think that will replace all existing TButton, TEdit, etc.). Maybe ways, but what will be the "golden way" (if there is any) ?

There are some quite old suggestions, regarding D.P.F., but I havent test it.

No ideas I could think of an interface system like FMX.Platform, to separate all features well. So that I could have multiple implementations, could override to fix something on the fly, and my features could be created by requesting the availability first. var LScreenService: IFMXScreenService; LScreenSize: TPoint; LMyService: IFMXMyService; begin if TPlatformServices.Current.SupportsPlatformService( IFMXScreenService, IInterface(LScreenService)) then begin LScreenSize := LScreenService.GetScreenSize.Round; ... if TPlatformServices.Current.SupportsPlatformService( IFMXMyService, IInterface(LMyService)) then //<= This checks if a feature is generally available (also kinda OS dependent) begin if LMyService.CanUseMyFull then // <= This could check if to what degree the feature is available at current OS-version begin LMyService.UseMyFull; // <== and use it fully if available end else if LMyService.CanUseMyPartly then // <= This could check if to what degree the feature is available at current OS-version begin LMyService.UseMyPartly; // <== and use it partly if available end; end; Would that be the perfect pattern to abstract such complex features also on different platforms and versions ? Mainly beauty may arise from a perfect naming system. Ideally I don't want to deal with version changes any longer, but simply want to use what is possily, to avoid crashes. The version requests are nicely hidden inside the services. But is this the best approach, is this really efficient and fits all needs ? Embarcadero decided for this to use it at the core, so it shouldn't be too bad, I'M not sure if there are better patterns available. I could also think about a messaging system, where all components communicate via publish/subscribe, which would ensure a very good separation, but that is not as easy to use as the FMX.Platform style. Another way could be simply by deriving features from a base class, to make use of normal class inheritence. Probably all different ways tend up to get messy soon, do I oversee someting ?

Can you please point out what low-end means, for what model are you targeting ? Are there any reasonable phones w/o hardware acceleration (beside maybe chinese lowest cost items) ?

Since Rio it has Z-Order for Android too.

Hi all, after tests with iOS 13 I see changed font appearances, and I hardly could find a device showing this. On my development devices iPhone X, etc. all at iOS 13.1.2 I didn't noticed that before. Only a customer point me on this, and I could get one iPad showing this error (also at iOS 13.1.2). It seems to change the fonts from some non-serif before, to a serif-kind appearance. When I check the font with IFMXSystemFontService, I got SFUI-Regular, 14pt at result This pointed me to this link. So something seems to be changed in the font-system. I cannot find any reference of SFUI related fonts in Firemonkey, so I assume this is not defined by Delphi. I've tried to set a custom font service, like this, but I'm not 100% sure if that really works and solves the problem. Since I have not build a separate tfone test yet, I cannot really check the font appearances in a nice way. Maybe somebody here has had similar issues, and could point me in the right direction ?

Thanks for the link, yes thats the same issue I see here. Not sure what font is chosen, but its unfortunately not even close to the original. Still I think that Apple changed their system fonts, so its not originally a Delphi issue. But Delphi has to fix it anyhow. That probably means that there needs to be a selection if iOS13 or < iOS13 is installed, to either fix it or keep as is. For me its important to keep the same look and feel on all versions. I've already tried to use the custom font service, I will try again to fix it with SFUI-Text next week, hopefully that is still available on iOS13. What I don't really understand is why this works on some iOS13 devices, and on some other devices it doesn't. Has iOS some secret differences between different Phones ? I would expect such differences in special hardware related stuff, but not with such simple things like system fonts. Maybe there are some settings in iOS which could correct this. I have read somewhere that some iOS 13 devices may run in a kind of iOS 12 mode, but I have not found more info about that. Thanks Apple, you've made my day again (and again and again ...). Would prefer to focus on Android 64-Bit tests instead.

I downgraded to SDK ios 12.4, and target device is still Ios 13.12. Now it shows SFUI-Text instead of -Regular. Hope that problem, among others, will be fixed soon.

I remember that I was able to download older iOS SDK at MemberCenter Downloads Other (some years ago), but now I cannot see any. In the web I found some very old notes, that XCode 11 should include at least the last 3 valid SDKs, but I cannot see them in the XCOde package. Only when I add a project, I could target this to iOS 12.4, and it seems to compile and run nicely, but I don't know where these iOS SDKs maybe hide. With General\Deployment info\Target I can make such changes. How can I do so, without iOS 12.4 ? When searching in the XCode\Contents\Developer\Platforms\iPhoneOS.platform\Developer\SDKs I only see iOS 13. What I remember from my earlier expeditions (years ago, since I haven't need to fumble in XCode for a long time now), that also other IOS SDK's may lay there, but I can find any. My plan would be to download the older SDK's somewhere, and copy them into above link, but I cannot really find the SDK file of e.g. iOS 12.4. One way would be to download XCode 10, to get the right SDK, but isn't there a smaller download available ?

I don't understand. I updated to iOS13 and in the SDK-Manager I updated to iOS13 as well. The XCode version is 11.1, the iOS SDK version is 13.1, what can go wrong here ? Do you have a reference, is this a problem from Apple ?

That is from 2014, so many iOS versions inbetween. I think the link I provided shows some hints that this could be an iOS issue, especially if the info.plist is correct. Maybe you need to add non-breakable-spaces or some other instead of a normal space.

Why not changing the project name, because of there are spaces in the name ? I try to avoid spaces at all cost, this I learned from too many lessons. You can use spaces in the AppStore title. Never tried: What happens if you use the project name with spaces (is that even possible) ? Maybe its a character issue in iOS: https://stackoverflow.com/questions/46337691/bundle-display-name-missing-space-characters How is this noted in the " "Info.Plist" file, maybe you can find some hints there ?

http://docwiki.embarcadero.com/RADStudio/Rio/en/Provisioning_an_iOS_Application Not sure if I understnad you right, but this is the desired behavior. The name of the Project (ModuleName) is taken usually as name, no need to make other changes Or are you talking about the AppStore, where you can set a app-name freely (more or less).