The iOS and macOS apps have been the biggest point of stress and frustration when building EteSync[1]. The API is buggy as hell and very limited (if at all available) and the review process is arbitrary and can cause updates to be rejected. You can never know if your workarounds will be accepted or rejected. Sometimes they can even get rejected in future app updates. The EteSync experience is subpar on Apple devices,…
> it's beyond me why would anyone willingly use an Apple product Final users don't see this mess.
I occasionally look after a fairly large Windows WPF application which is half integrated with Microsoft Word and there are hundreds of lines of code dedicated to quite horrible workarounds for issues caused by API changes and weird ass behaviour. There are a lot of if statements for different Word versions as well.
For example: when saving a file "safely" (i.e. without weird ass side effects such as locking or document metadata corruption), if your word version is 7, 8, 9 or 10 you must use SaveAs2000 API call. If your word version is 11, 12 you must use SaveAs API call. If your word version is any other one then you need to use SaveAs2. This is entirely not documented past telling you that you are told not to call half of them and most of the reasons behind using them were discovered by taking the VSTO libraries to bits.
At the end of the day, the objective is to make sure the end user never sees the hell you had to go through and entirely takes your efforts for granted. They don't care and efforts to appeal to them are frowned upon, even if we whine and complain about it in our own circles.