Is anyone working on an iOS app?

[Dirk Hohndel]

On Mon, Oct 12, 2015 at 01:56:49PM +0300, Miika Turkia wrote:
> > Does that mean that the dives I imported from my computer will never make it into the iOS app? It sounds like as the workflow is
> > Log in iOS with gps
> > Sync with ssrf
> > Add meta data
> 
> This is what we currently have. The iOS app only logs the GPS data and
> that is it.
> 
> > Sync back
> 
> This is currently not possible and it was never intended to occur with
> the existing iOS app.
> 
> > Does not make sense to me at all and is not user friendly.
> 
> Well, it depends. The current app is designed to only collect the GPS
> information and nothing more. For that it is easy enough to use, but
> it seems that most of the people are actually expecting more from it
> and thus the concept is hard to grasp.

Yes - I learned that this amazingly useful app that I use on every single
dive trip appears to make no sense to a lot of people who simply have
convinced themselves that the app SHOULD be doing something else and then
when I try to explain the really cool thing that it does they don't even
listen and all they think is "but it doesn't do the thing that I WANT -
that's STUPID"... :-)

> > Apparently I don't understand this.. Hence will try to find the documentation and don't bother you guys any longer.
> 
> Basically you should forget about the current iOS app for what you are
> thinking. Current one only logs GPS data, it is not the app you are
> thinking of :D

Yes. Forget the COMPANION apps. We have a companion app for Android, we
have one for IOS. Neither are the ones that you are looking for.

> We already have a prototype for Android of a mobile app that is able
> to sync the dives and display them on a phone/tablet. And this is what
> we are now discussing for iOS as well. If you want to take a look at
> the Android app, there are emulators on Android SDK where you can run
> the app.

And that is the app we should use for IOS as well.

The way this works is (roughly) like this:

We run a big subset of the full Subsurface application on the mobile
device including a QML based mobile UI. Qt/QML are supported both on
Android and IOS.

There's a little "glue" layer that integrates that native app into the
mobile OS. And THAT is the first step of what you should do and it makes
perfect sense to do that right now. Figure out how to create an IOS
wrapper for a native Qt/QML app. Send patches to add this to master.

For Android we have a build script that allows you to build all the
dependencies using the android tool chain. My guess is we need this as
well as the "wrapper" or "glue" around Subsurface to make it launch on
IOS.

I'd start reading here: http://doc.qt.io/qt-5/ios-support.html

Did this make more sense and explain the direction I think this should be
going in? If not, keep asking... I'd hate for you to waste time staring at
the companion app and trying to figure out how to extend that to be what
you want it to be and I'd hate for you to waste time developing a new UI
when we already are working on a mobile UI in a framework that should
allow us to reuse the vast majority of that work on IOS as well.

Thanks

/D