I have project that will have multiple clients: web, Android, iOS and probably a desktop version too.
As I see a few technologies that claim to help me with this like Flutter, React Native, Native Script, Xamarin(?) and others, I do not know which ones might fit (and of course I do not want to study all of them only to find, in the end, that something I wanted is missing).
[As I do not want this to be tagged as a "opinion-based" question I selected a few specific questions that should give an objective information on each technology someone might mention - more or less similar to a feature matrix]
Here are a few questions that a technology / framework should pass in order to be a good pick
Can I write a single code and then have builds for separate platforms? Or to what degree can I do that? Does it look decent (native) enough on a specific platform?
What additional installations do I need in order to obtain a build for a platform? (Ex: Do I need to install Expo Client for React Native in order to be able to run the app on device?)
How easy is to access the native API in case I need it? (Run it in background, battery level, screen brightness, services, file system access, etc.)
Can I write also server side code with it? To what degree? (Ex: Can I put Dart on server side?)
What is the level of support from industry and dev community on it? (Is it backed more by a company or community?)
Please mention any other platform that I might not mentioned and you have experience and can fulfill the requirements.
Related
So, my aunt wants me to make an app to help people create lists and be more organized. It would also have pre-made lists and tips that occasionally appear. We both want it to be for iOS and Android. Does anyone have recommendations for what software I could use to create something like that? One other thing to note: I can't use XCode because I'm not a mac user. Thank you for your input.
This question depends a lot in preference and personal opinion...
Unity is my personal favorite tool to deploy in multiple platforms and even if its a game engine I have used it for simple user interface aplications with very little effort and bug count... the withdrawals are that you use a "lot" to make so little... the whole physics engine does nothing and the apk weigths at least 20Mb ... but its a very simple tool that could do the job in a couple of days having little experience and thats what i like about it.... theres also Xamarin C# , Android studio... React.. Depends a lot on your liking...and personal preference.
If I were you, I would go for React Native it is a mobile apps building framework using only Javascript!
Here is a showcase of real-world apps using RN: Who's using React Native?
I've got a big ask here, but I am hoping someone might be able to help me. If there's another site you think this should be posted on, please let me know.
I'm the developer of the free app Amphetamine for macOS and I'm hoping to add a new feature to the app - keeping a Mac awake while in closed-display (clamshell) mode while not having a keyboard/mouse/power adapter/display connected to the Mac. I get requests to add this feature on an almost daily basis.
I've been working on a solution (and it's mostly ready) which uses a non-App Store helper app that must be download and installed separately. I could still go with that solution, but I want to explore one more option before pushing the separate app solution out to the world.
An Amphetamine user tipped me off that another app, AntiSleep can keep a Mac awake while in closed-display mode, while not meeting Apple's requirements. I've tested this claim, and it's true. After doing a bit of digging into how AntiSleep might be accomplishing this, I've come up with 2 possible theories so far (though there may be more to it):
In addition to the standard power assertion types, it looks like AntiSleep is using (a) private framework(s) to apply non-standard power assertions. The following non-standard power assertion types are active when AntiSleep is keeping a Mac awake: DenySystemSleep, UserIsActive, RequiresDisplayAudio, & InternalPreventDisplaySleep. I haven't been able to find much information on these power assertion types beyond what appears in IOPMLibPrivate.h. I'm not familiar at all with using private frameworks, but I assume I could theoretically add the IOPMLibPrivate header file to a project and then create these power assertion types. I understand that would likely result in an App Store review rejection for Amphetamine, of course. What about non-App Store apps? Would Apple notarize an app using this? Beyond that, could someone help me confirm that the only way to apply these non-standard power assertions is to use a private framework?
I suspect that AntiSleep may also be creating a virtual keyboard and mouse. Certainly, the idea of creating a virtual keyboard and mouse to get around Apple's requirement of having a keyboard and mouse connected to the Mac when using closed-display mode is an intriguing idea. After doing some searching, I found foohid. However, I ran into all kinds of errors trying to add and use the foohid files in a test project. Would someone be willing to take a look at the foohid project and help me understand whether it is theoretically possible to include this functionality in an App Store compatible app? I'm not asking for code help with that (yet). I'd just like some help determining whether it might be possible to do.
Thank you in advance for taking a look.
Would Apple notarize an app using this?
I haven't seen any issues with notarising code that uses private APIs. Currently, Apple only seems to use notarisation for scanning for inclusion of known malware.
Would someone be willing to take a look at the foohid project and help me understand whether it is theoretically possible to include this functionality in an App Store compatible app?
Taking a quick glance at the code of that project, it's clear it implements a kernel extension (kext). Those are not allowed on the App Store.
However, since macOS 10.15 Catalina, there's a new way to write HID drivers, using DriverKit. The idea is that the APIs are very similar to the kernel APIs, although I suspect it'll be a rewrite of the kext as a DriverKit driver, rather than a simple port.
DriverKit drivers are permitted to be included in App Store apps.
I don't know if a DriverKit based HID driver will solve your specific power management issue.
If you go with a DriverKit solution, this will only work on 10.15+.
I suspect that AntiSleep may also be creating a virtual keyboard and mouse.
I haven't looked at AntiSleep, but I do know that in addition to writing an outright HID driver, it's possible to generate HID events using user space APIs such as IOHIDPostEvent(). I don't know if those are allowed on the App Store, but as far as I'm aware, IOKitLib is generally fine.
It's possible you might be able to implement your virtual input device using those.
I'm working on a new project for a Fintech company and I have been tasked with looking into whether we should go with React Native or native Swift/Objective-C/Java for our mobile app development technology and strategy going forward.
I have done loads of research into this and have read many of the case studies relating to React Native, but I still don't feel I have enough to make an informed decision at this point.
The broad app functionality will include things like:
Data related functions such as Account Balances and Statements (pretty simple)
Image capture of identity documents and selfies of the users
Capture of biometric data
Push notifications
Some of this is pretty standard and simple, but some of it will require the app to use low level device functions and/or use 3rd party Android and iOS SDKs.
So, in terms of working towards the decision of a mobile development strategy, can I ask you for your input, based on your recent experience, on reasons to consider React Native over native Swift/Objective-C/Java development in the light of the planned functionality listed above (including reasons why it may be far better to stick with the native languages/platforms).
From own experience I can tell that React Native is a good choice for most of the apps when you need to develop and iterate fast. It usually means it would be cheaper to develop for a customer.
Looking at the list of features I can not see anything that can not be done in RN. Sooner or later you'll have to dive into native code, usually to bridge native modules with JS. I've done this multiple times, it's not that hard and documentation on RN website helps a lot.
Be aware that you'll most certainly run into stupid bugs and you'll have to find workaround. At least this happened to me multiple times when I was building RN app half a year ago, maybe now it's more stable.
Also I believe it really depends on what are the devices of potential app users. I've never developed for Android, but heard from fellow developers, that on mid-level Android devices RN runs much slower, this should be tested from the very beginning.
React Native has a really nice and tempting idea behind sounds like "unified and almost fully shareable codebase for different platforms including Web". But from my experience (not so extensive but still) the reality is a little bit different – at some point you will face some issues with native code for sure, and it would be really good if you have experienced Swift/Objective-C/Java developers in your team to deal with it. Don't trust the promises "all you need is just a React Front-End Developer". The React Native platform itself seemed to me more like a magical blackbox which I ran with a single command having no any idea what's inside and how it actually works. You have to know at least something about Xcode and Android Emulator even if Facebook is trying to hide this aspect it from you as much as they can.
TL;DR In my opinion if you really want to try React Native for something more complex than TodoMVC then you need to have at least 3 developers: Web (JavaScript/React), iOS (Swift/Objective-C) and Android (Java). Or just one Superhero.
I am considering making a small app for desktop pc's. I would mainly like to have support for mac and for ubuntu (linux) and I wouldn't mind support for windows as well. An easy way seems to develop an app using Unity, but it is more known to be an engine for games.
To my simple logic, there should be no reason why an app cannot be built with Unity. A platform that features the ability to create massive laser marine gunbattles should be capable of rending pretty buttons and a user interface. The plus side is that with unity you can port to all platforms that I would like this app to run on as well.
Am I making a bad assumption? Are there any people that have done such things? The app I would like to make might be open source, does the Unity platform limit me in any way here?
You are correct in your reasoning that it is possible to make a normal app with Unity, but this of course is not what Unity was intended for. It is geared towards rendering and updating scenes (including physics, game logic, etc.). If you do not need the notion of scenes in your app, then you will add additional complexity to your development and run-time overhead that you would not normally need.
Another drawback is that you will need to abide by Unity's licensing with your app which may or may not be an issue for you (https://store.unity3d.com - See links at the very bottom for other special licenses, such as for gambling).
Since you mentioned Unity specifically, it uses Mono for some of its run-time support across platforms. Perhaps you want to consider using just Mono and associated tools instead (http://www.mono-project.com).
So GWT best practices encourages one to use some flavour of MVP, which should in theory allow one to write different native views while sharing the presenter business logic.
This seems to be at the heart of the GWT spin off Google project http://code.google.com/p/j2objc/ which converts the non-UI part of your code to Objective-C, allowing you to write the rest natively in Objective-C.
So my question is: If this really hard part of the puzzle is being solved, how hard would it be to include an HTML5 mobile library (like MGWT or Touch4j [Sencha]) into this MVP pipeline to have the best of all worlds?
Having dabbled with http://code.google.com/p/playn/ , this clearly seems to be the blue-print for having a cross-plaftform build system (native android & html5 & java &...), but that project is geared for single screen drawing and event loop for game dynamics and doesn't allow for keyboard input and other typical mobile goodies.
It seems a shame that if so much of the problem has been solved, that it's not possible to go the extra mile. The answer to this question would be the best plan for actioning a solution, including such nigglies as which MVP structure to choose that would ease accommodation of the various widget libraries (GWTP vs MVP 2.1), and if the best approach is to start with the PlayN code base, and start to hack it.. what are the gotchas? Or if another path is chosen, why that one? and why would it be the best??
Thanx a lot. :-)
It is not clear whether your question is - evaluation options for multi-platform app development or mvp.
You can evaluate additional technology which are used with Sencha and GWT
1) mgwt
2) titanium
3) phonegap
You can also reference - Creating a mobile app using Google App Engine and GWT?
Note: PlayN as you mention is more of gaming platform and not suitable for business app.
MVP is definitely doable... and at times you may feel like its a lot of work, but it pays off in the end. Check out the Touch4j Kitchen Sink, which is written using MVP. You can take that down to the device with Cordova if you wish. The code is on GitHub:
https://github.com/emitrom/touch4jks
The repo is actively being worked on (we are updating ourselves to Touch4j 4.0) so it won't run out the gate, but at least you can see and follow the model :-)
Titanium4j is to Appcelerator's Titanium as Touch4j is to Sencha Touch. You may want to check that out as well. Titanium4j and Touch4j rely on GWT.
Cheers.