iOS Feasibility Question

I have been writing Xojo for some time but have not yet done ANYTHING for iOS.

I have what is a fairly small desktop application ( 8-10 windows and a SQLite Database with 7 tables) that I would like to port to an iPad.

I have prototyped it using FileMaker and it seems to work well - navigation in FileMaker Go is pretty much built in with no coding required.

I understand I will have to build a completely separate application for iOS but I need to to use the same SQLite database. I understand iOS and SQLite are completely compatible.

So the problem I have is how to build the navigation for that many different layouts/forms/windows in Xojo - the desktop app just uses the standard mainmenu function. It’s going to be hard enough to redesign the screens to fit on an iPad, several of the windows have tab controls with 3-4 tabs. But how do I build the navigation. The sample projects I have looked at (at least the ones I’ve found so far) are pretty simple apps.

I also will need to design a set of tables to transfer updates made on the iPad back to the desktop but that’s another issue.

Any advice, or hopefully a point to an applicable sample, will be greatly appreciated.

Incidentally, you maybe able to use a great deal of your present logic with the help of XojoiOSWrapper which I created originally for my own use in order to port older code and not have to rewrite everything in new framework.

As far as design is concerned, paradoxically, the best document I know of to port Desktop apps is the Windows UWP apps design guide. Microsoft has put a great deal of thought into porting desktop apps to full screen, kiosk, tablet apps with no windows, no menu. Well, when I say no menu it is not entirely true. They tend to replace menus by panels that appear with a swipe or a button click, and contain a table (equivalent of Listbox) with the options. When an option is selected, the panel disappears. That should allow pretty rich navigation.

Tabs on each screen are not an issue, it is a part of iOS design. See the iOS Human Interface Guidelines.

Keep in mind also that the keyboard takes about half the real estate.

Without seeing your app’s UI, it sounds like you will start with a view that lets you pick which of your 8-10 “windows” you can navigate to. I would say use a tab panel, but it won’t hold that many choices. Well, it might if you’re limiting this app to just the iPad. Selecting an option should push a new view onto the stack and display it, and leaving that view should pop it off the stack and return you to the main view. On any view, if you want something like a pulldown menu, then you will push a new view onto the stack with a table to make your selection and pop it off the stack when the selection is made. That’s your basic iOS app right there: Pushing and popping views or using a tab panel like the page panel in a desktop app.

but a properly designed iOS app will detect the location of the textfield and scroll the screen so the keyboard doesn’t cover the field, and move it back as appropriate when the keyboard is either dismissed, or you move to another field.

Indeed. But yet, in practice, whenever the on screen keyboard is displayed, only 50% of the screen is visible. Which means even less room for the UI

7 6/8th x 3 inches. Heck, about the size of a check. Precisely my Check Writer app is way simpler than what the OP described, and yet, when I tried to mock up what it could be in iOS, it was kind of nightmarish. In OS X, both check and accompanying letter are displayed. In iOS, that becomes impossible.

Same thing to display a table with the classic columns date, check number, payee, for, debit, credit, balance, check/reconcile.

Not saying that is impossible, it is only very challenging when one ports a desktop app.