Leaderboard

Our iOS app, EarMaster, made with Delphi is now featured in App Store, in the "Best of the month - New apps we love". Nice to see that a Delphi app can get this kind of approval from Apple. PS. I am in Denmark, so I see the Danish app store, but I am curious to know, in what other countries it has been featured too?

Dave, you're the "Killer". Thanks a lot for this change in your demo. If i compare your project with mine the difference is: yours: FireDAC.Stan.Intf, FireDAC.Stan.Option, FireDAC.Stan.Error, FireDAC.UI.Intf, FireDAC.Phys.Intf, FireDAC.Stan.Def, FireDAC.Stan.Pool, FireDAC.Stan.Async, FireDAC.Phys, FireDAC.Phys.SQLite, FireDAC.Phys.SQLiteDef, FireDAC.Stan.ExprFuncs, FireDAC.ConsoleUI.Wait, FireDAC.Stan.Param, FireDAC.DatS, FireDAC.DApt.Intf, FireDAC.DApt, Data.DB, FireDAC.Comp.DataSet, FireDAC.Comp.Client, to mine: FireDAC.Stan.Intf, FireDAC.Stan.Option, FireDAC.Stan.Error, FireDAC.UI.Intf, FireDAC.Phys.Intf, FireDAC.Stan.Def, FireDAC.Stan.Pool, FireDAC.Stan.Async, FireDAC.Phys, FireDAC.Phys.SQLite, FireDAC.Phys.SQLiteDef, FireDAC.Stan.ExprFuncs, FireDAC.FMXUI.Wait, FireDAC.Stan.Param, FireDAC.DatS, FireDAC.DApt.Intf, FireDAC.DApt, Data.DB, FireDAC.Comp.DataSet, FireDAC.Comp.Client, Using your used units solved all hangers + i have removed the datamodule-unit and restclient-unit also from project files. Everything is now working for some minutes without problems, very coool Thank you very much,

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.

Yes, we released a new build 2 weeks ago, which is the first one made with Delphi 10.3.3. So far the crashes are lower than the build with Delphi 10.3.2. In return, the new build has been featured on App Store, so I believe that Apple is quite satisfied 🙂

German store has ist too. Congrats!

Glad to hear it's helping you! 🙂

Build the dcus into a dll and link to that. You can't use packages because you can only link packages that were compiled with the same compiler. That's a short term solution. Long term you should replace the library.

https://github.com/danieleteti/delphistompclient

I think habarisoft make this https://habarisoft.wordpress.com/2019/06/10/apache-activemq-artemis-2-9-0-released/

Hi All, thanks for trying to help me out. Now after i was able to debug the android-service by creating a lot of toslog.d entries and viewing them in realtime with help of the DeviceLens Tool we see that the problem is not only the Data.DB! If we use Data.DB (i had defined $ifdef's for this) then we have used also a function as described in And there is also the problem. Each time the service calls that function with a + in a string it gets appended to a server-method-call within the url and the service stops working because of an exception http/404! I was not able to see this because the service is not debuggable from Delphi (afaik). Now after doing a check of strings / url-encoding them it works but this seems to be a bug in latest Rio Restserver / restclient impementations ... But using Data.DB also forces the service to hang, it can't even be started!

Indeed; Hierarchical lock schemes are notoriously difficult to get right and most people don't even realize that if you have nested locking then you need to have a hierarchy. ... is pretty much a guarantee that one will happen sooner or later.

See here: https://github.com/DelphiWorlds/DeviceLens Thank you DelphiWorlds! This is helping me more than everything else for debugging my Android-Apps

I've just checked in changes to this demo that include posting the location updates to a SQLite database. Service starts OK in it, at least for me.

Good news about iOS crashes! I owe Embarcadero and all of you to show the updated crash report graph. The problem was an internal hard limit in librtlhelper.a on the number of OC wrappers that could be created. As my app uses the TMC iCL native components, and is a large and comprehensive app, it wraps thousands of OC objects. Each new Delphi version used more and more OC wrappers on its own, leaving less for use in the app. That's seen clearly on the previous graph I showed. Marco sent an updated version of librtlhelper.a to me with a higher internal limit, and the result is seen clearly on the graph below. There are still some crashes though, which might indicate that a some of our users still reach the limit, <irony>since I can't imagine that there can be other errors in our software</irony>.

I understand how you feel. Sometimes it is going two steps forward three steps backward. One of the problems with cross-platform development is that not all code is the same. And different principles apply. OS architectures are different and what you can do on one platform, you cannot do on another. I am talking generally, regardless of whether offending code is yours or Embarcadero's. Also mobile platforms change frequently and are also changing rules and behaviors. What worked today, may break tomorrow. This is not related just to Delphi applications but all. I am using Xcode - Swift and Android Studio - Java for mobile development and situation is not much different. The only difference, is that when some policy or behavior changes, you immediately have appropriate tools to implement change. But your code will be broken left and right. You cannot take year old code and make simple recompile - in Swift everything is in a state of flux - language, frameworks, so every time you touch it, it is almost a rewrite. I don't even know what is the proper method for sorting list - its name changed dozen times - from sort to sorted to sort again... what is current one I have no idea - and that is just the simplest example. On Android, Java is the same, but frameworks are changing every week. If you have to support newer versions of OS, you have to use newer frameworks, that also change all the time, are buggy as hell... I know Delphi could and should be better. But, I also painfully know that grass is not greener on the other side. What we can do, is relentlessly report issues to Embarcadero. Not all will be fixed and not all will be fixed as fast as we would like, but Embarcadero is fixing them. Especially, more critical ones.

This is interesting stuff. What produces the above stats? (As background: Back in when XE5 was released we did some evaluation and based on the admittedly somewhat limited testing we did, concluded that mobile support was [at that time] not good enough to risk a project on. I/we have generally however had the impression in recent releases (since let's just say 10.x) that support was plausibly nowadays "good enough" based on generally favourable anecdotal reports by people with production apps in the Google and Apple app stores. We have therefore been considering revisiting and doing another trial and possibly proceeding with a mobile app development soon. However the above puts a slightly more cautionary spin on things. So your report is useful, thanks, and any further comments are highly appreciated.)

Yes, I have the graph by OS also, but in both situations where the the graph stepped up, it happened with the same OS. So that is not the reason.