Yet another JUCE iOS app


#1

Hi everybody. Yet another JUCE based iOS app has been approved for the appstore - and this time first time out! Thanks to everybody who posted their experiences, it's been very helpful. I was actually afraid that they would reject it first time,  but maybe they are more lenient with free apps. The app is https://itunes.apple.com/us/app/cromble/id896491985

My experiences in trying to get it approved are:

  • The GUI is "roll your own" using the LookAndFeel classes and a commercially available UI kit. It doesn't follow the style guide, but it doesn't try to imitate anything iOS7 does either
  • For scrolling lists I did use the native iOS viewport, using a tweak on the module provided by Aiit at http://www.juce.com/forum/topic/juceiosviewport - thanks for that.
  • Alert boxes are all native
  • Although the guide says that apps that are heavy battery drainers will be rejected, because the app is deisgned for low latencies with a 64 sample frame size and realtime compression/decompression, you can't avoid hammering the CPU. I took the trouble to explain this carefully in my submission and that seems to have worked.
  • Because the app is client-server based I was able to watch quite a bit of what they were testing by monitoring the server, and yes: they do test everything

Anyway that's done, now all I have to do is persuade people to use it.smiley


#2

Good stuff! Best of luck with it! :)


#3

Congrats! I will download and check it out.

I will have to check out the listbox stuff. I am currently using a list that you have to drag the scrollbar to browse, and can see that causing my app to get rejected.

and as far as power usage, yeah well that's pretty much unavoidable. I know of many approved apps, not just music apps but also for example navigation, that make excellent space heaters on a cold day.


#4

BTW the reason that I used the native iOS scroller was that I needed to replace my original solution, which was a hack on the juce listbox which added the ability to drag things off the list into another component. Unfortunately the performance was agonizing and that's why I moved to the native solution.

There is, however, a price to pay. For some reason, if I have these scrolling elements on the screen and switch to another screen, the scrolling elements don't go away. I think it has something to do with the UIView heirarchy, but I don't really know enough iOS and will have to dig into this at some point.  I currently use a horrible kludge where the parent screen is set to a size of (1,1) and resized when the new screen exits. If anyone knows of a better solution, I'd be glad to hear it.