Our company has built a fairly standard hybrid webview using Xamarin Forms and targeting ios and Android.
We intend to point this webview at an existing web application, build the native applications and submit them to the apple store for review.
I have concerns after reading articles suggesting that Apple could reject if they feel the native app doesn't add 'value' beyond the web application. We had a few additional requirements that we implemented in the application.
- An intro launch screen using a native carousel. This way launch this carousel in the app the first time the user opens the application. After the user logs in for the first time, they are no longer shown this carousel.
- Once . user logs into the app, we no longer require that user to log in
- If their internet connection goes down, we show a 'network disruption' view and ask them to try again later.
- We use the native tabs feature to show tabs at the bottom of their screen. The webview is shared between views managed by the tab, but when a user clicks on a tab, it directs them to a specific page in the web application.
- We show a native 'launch' page while the sited str loading.
In the future we would like to take advantage of push notifications and other native features
Our xamarin developer has moved on. There are a few things that we I require:
1. A proper continuous integration strategy. As of now, the only way to build the project is to open visual studio and run it. We would prefer that as code is committed, the build server should check that code out, and build it. The build server should also provide a way to submit an artifact to the app store and play store for testing.
2. The Xamarin project is not large. It is maybe 20 files of fairly straightforward code. However, it is undocumented and potentially has bugs. We would like somebody knowledgeable in xamarin to go through it and document the code, clean the code, and point out any potential issues that they may see.
By 'clean the code', I do not mean refactor. Just make sure the solution and its files are adhering to a convention. Currently it sees like there wasn't much thought put into variable names, method names, and so on.
By 'document the code', I mean learn what a method does, and put a comment above the method explaining it; If there is something unobvious in the body of the method, please comment that as well.