NativeScript roadmap: Desktop support no longer on the cards? - nativescript

I notice that desktop support isn't mentioned in NativeScript's future roadmap any more.
Has this been dropped for good, or is it still on the cards?
If it is still on the cards, for when is it planned?

NativeScript under Progress ownership
While NativeScript was owned by Progress, desktop support was never a priority; developer surveys did not show strong enough demand for it, and the NativeScript Core team were stretched too thinly to tackle it as a curiosity.
Of interest, before the death of Windows Phone, NativeScript did get very far on implementing a Universal Windows Platform runtime for NativeScript: https://github.com/NativeScript/windows-runtime
The NativeScript iOS runtime (https://github.com/NativeScript/ios-runtime for JSC, https://github.com/NativeScript/ns-v8ios-runtime for V8) is also close to delivering Catalyst support, although it's essentially undocumented for now.
I spoke with the NativeScript iOS runtime team and they said it would be pretty trivial to generate JS bindings to macOS (AppKit/Cocoa), too – though one would still have to implement all the UI components as AppKit ones, so it would only be the start of the journey.
Unofficial support
Kamen Bundev (on the Progress/Telerik NativeScript team) has been building a Qt-based desktop implementation of NativeScript as a hobby project for a long time:
https://github.com/bundyo/nativescript-platform-desktop
It has access to Node.js's APIs rather than, say, the Obj-C runtime on macOS, however.
NativeScript under nStudio ownership
NativeScript was recently handed over to nStudio, who may have a different stance. This question did in fact receive an official answer recently on Twitter:
They have also expressed love for the idea of creating Windows 10 apps with it (the tweet links to this issue, https://github.com/NativeScript/NativeScript/issues/8643):
My personal speculation
Note that I do not work for nStudio, and the dust is still settling after the NativeScript handover, so everything from here is just speculation:
So I think there's no question that the passion is there – the real question is whether they have the resources to back it. I personally think that there won't be any movement on it anytime soon, as nStudio need at least a few months just to get used to driving the NativeScript ecosystem and sorting out the long-standing open-source frictions. I think that they'd absolutely welcome a community-driven effort on this, of course. I imagine that by 2021 they'll feel more ready to take on projects of that scale.

Related

Struggling to find good Examples of iOS app clip & Android instant Apps

I've searched for examples of iOS app clip & Android instant Apps but could not find more than few examples.
I am looking for released apps in App Store/Google Play or open source examples.
good examples could make developing these new features easier and gives developers new creative ideas to use these wonderful tools.
Do you have an app that utilizes App clip or instant app?
How did this affect your app?
What is the challenges you have faced?
Note: I know this is not a typical question but it need to be asked in a community full of great developers who love to share knowledge with others, and I don't think there is a better place than here.
Intro
I know it's been 10 months since you posted the question but I just stumbled upon it now... I've developed an app called ARShades for both iOS and Android that allows the user to try glasses on via Augmented Reality and I'm still in charge of development. The app supports both Instant App and App Clip, although I'm facing troubles making the the app banner show for the App Clip.
Firebase issues
As far as I can tell developing App Clips is a tad harder than develeloping Instant Apps, I'll tell you why. The main apps for both systems make extensive use of Firebase Firestore and many other features. This isn't a problem on Android where sockets are supported across the board, while on iOS they are only supported in the main app, so I had to use REST API to read and write data on Firebase when developing the App Clip, it's been a nightmare since it was the first time for me dealing with REST APIs (I just finished yesterday and published the update).
App Size
Another issue I faced is related to reducing the app size. On Android I had to remove all the unused images and compress the remamining ones. On iOS I had to separate the asset catalogues between: used only by the main app, shared, and used only by app clip. And of course I went through some compression works there too. I forgot to mention that I developed a new app as Instant App on Android, while you cannot do the same on iOS since it must be in the same project.
App to site linking
Another insidious part was the linking of the site to the apps. I managed to do it on Android by making changes to the manifest and specifying the host, while I can't seem to find a way to link the App Clip to the site in ay way. I've done everything the documentation says. I've put the apple app site association file in the .well-known folder but nothing, no banner shows up. I'll keep working on that.
Edit: Everything is now solved.
Conclusions
So, to sum up, I've found Instant Apps better on the developing and hassle side of things, the support sockets, hence the full suite of frameworks the full apps have. I hope I kind of answered your question, although I think you have documented yorself elsewhere in these past 10 months XD
Links to Android: https://play.google.com/store/apps/details?id=it.spaarkly.arshades&hl=en_US&gl=US
Link to iOS: https://apps.apple.com/us/app/arshades-demo/id1586661818
Link for trying Instant App / App Clip

When will Nativescript for Windows mature past the proof of concept stage?

The readme.md at https://github.com/NativeScript/windows-runtime says that the Windows runtime for Nativescript is in proof of concept stage, and then lists what I understand to be very deep language features that are not implemented yet.
The tone on the https://www.nativescript.org/blog/nativescript-runtime-preview-for-windows-10 announcement seems a bit more enthusiastic about the current feature set.
Being able to use Nativescript on Windows Phone (and any other platform) is incredibly appealing.
TJ, a core team member, recently posted on the forums about this:
Hey #NezzaGrey,
Thanks for reaching out, and awesome that you’re liking NativeScript :smile:. >Straight to the point though—we’re not actively working on UWP support because >1) it’s a ton of work to add a new platform and commit to supporting that >platform indefinitely, and 2) we’re not seeing nearly enough demand from our >community to justify taking on that work.
That doesn’t mean that UWP support in NativeScript will never happen, but it’s >not coming in the short term because we’re just not seeing the demand. That can >always change though. I’d encourage you to add your use case to the GitHub >issue open for adding UWP support in NativeScript: >https://github.com/NativeScript/NativeScript/issues/254. Yes, the issue is >somewhat ancient, but we really do pay attention to well-thought-out comments >during roadmap discussions.
I’ll note two other things. First, our initial work on making a Windows runtime >is completely open source and available on GitHub: >https://github.com/NativeScript/windows-runtime. We’d love to have community >?>help to make the new runtime a reality.
Second, one option you have is to build your iOS and Android apps with >NativeScript and Angular, and to use our code sharing approaches (see ?>https://www.nativescript.org/blog/code-sharing-between-web-and-mobile-with->angular-and-nativescript1) to share your Angular code with other apps. You >could take that approach to share Angular code between your NativeScript apps >and your UWP apps if you use something like Electron. This approach isn’t >ideal, as you’d probably prefer to build a completely native UWP app, but it’s >something to consider if you’re open to using Electron.
Anyways, hopefully you found some of this helpful. If you have any other >questions feel free to follow up.
Source: https://discourse.nativescript.org/t/windows-uwp-support/2659/3

Ionic 2 vs Xamarin

I have found a lot of articles (and forms) about Ionic vs Xamarin but they always talk about Ionic 1 or Xamarin when it was still paid for (so before march 2016 when it was acquired by Microsoft).
I have to research Ionic 2 vs (current) Xamarin and I know that both technologies have made huge advancements. Can anyone help me on my way with some sources or is it still too early to ask this question?
Xamarin: With one year of experience, I have realise it is really flexible IDE to use. The amazing part about Xamarin is you have 2 option, i) go native ii) go cross platform, this make it open on what kind usage you prefer and how you want to go about.
OS Support/Deployment to: Windows, iOS, Android, Mac
Languages Used: XML, C#
Ionic: especially Ionic-2, It amazing for all HTML, CSS, and JS users to build application for web, mobile applications. I haven't seen its deployment for windows phone(if it is, then i am not sure) With Ionic, forget all your MVVM structured coding. But the new implementation of version-2 parallel with angular-2(typescript) it might make it possible to implement.
OS Support/Deployment to: iOS, Android, Web(HTML/CSS)
languages Used: HTML, CSS, Angular-2
Star Rating
Xamarin - Mobile and PC Dev - 4/5 stars on usage of IDE and deployment. There are immediate help available upon stuck through Xamarin Forums. Documentation is little vague.
Ionic-2 - Mobile and Web Dev - 3/5 stars on usable and compatibility. Its hard to find some answers to specific question, rest ionic docs are great at documentation and implementation.
Hope this helps. PS: This is completely my own view as i have used both of this tools personally. Comments are welcomed.

Xamarin cross-platform user experience vs. native development

I am trying to evaluate whether Xamarin would be a good option for my project. The project is a large, complex app for Android and iOS with a lot of client-server communication. The user interface is a major focus and has to be really fast and smooth. Also, we plan to make large use of UX graphic effects (comparable to the Spotify app).
For now we are planning to go for two separate native apps using Java/Objective-C. However, the possibility of cross-platform code sharing would be very convenient for us of course.
Most opinions I've heard so far say that Xamarin - although far better than HTML5 apps - cannot match the UX of a native app. Also, I tested the following applications made with Xamarin (on Android):
Rdio
MarketWatch
Busch Gardens Discovery Guide
Sqor
Storyo
From my impression, none of them could quite match the speed and smoothness of a good native app.
If our focus is on a top notch user experience, would Xamarin really be a viable option? Can it really match a native UX? I am particularly looking for opinions from developers who have experience with large and complex cross-platform Xamarin applications. A few critical voices would be very helpful.
Thank you a lot!
I'm on the Rdio mobile development team, so I can make some personal reflections from that standpoint.
Xamarin allows you to write native applications in C#. Any slowness, jankiness, ugliness or bad-appiness usually has nothing to do with the Xamarin layer itself.
You save some time being able to share core business logic between your different clients, but you're still writing the UI from scratch, specific to the platform. You're just writing it in C#.
But while you save that time, you're spending it in other ways. All of those SDKs you want to use probably aren't compatible with Xamarin out of the box. You won't be pod install'ing that iOS framework, and you might be reinventing the wheel for handfuls of things. Xamarin takes advantage of the NuGet repo so you have a library of components that handle many of the things most people need (Analytics, Testing, Facebook SDK, JSON parsing, Database, etc etc) but it doesn't cover everything. And it certainly doesn't cover stuff that's out the day of an Apple or Google product announcement.
Any 3rd party code that you do want to import into your project will be done through writing custom bindings. While not usually difficult, it is time consuming. Xamarin has a team of people that specialize in assisting you in this. This fact speaks to the process being messy at times.
So while the slowness, jankiness, ugliness or bad-appiness probably isn't the fault of Xamarin, it might be the fault of you spending time in places you normally wouldn't, or not being able to take advantage of features you normally would. If that 3rd party partner SDK is giving you problems, your troubleshooting may take twice as long because there's a layer that you don't control.
UI is a wash. You're writing it from scratch anyway.
Business logic is shared. Depending on the app that might be a win if you architect your application to take advantage of it.
Compatibility / bleeding edge ability will be lacking. That might not matter to you at all, or you might be the person wanting to take advantage of that hot new API in the next OS release the day it's announced.
My personal thought, without knowing specifics, is if you want to build an application that you plan on being around years from now, and that will take advantage of the latest and greatest, I'd tell you to write natively for each platform. Unless you can really see huge gains in sharing that business logic the upfront gains are minimal. Or if you really like C#.
Xamarin uses native controls. So you design a fully native UI per platform. The users can't see that your App is made with Xamarin or Java/Objective-C.
There are sometimes performance issues in conjunction with the platform independent UI wrapper Xamarin.Forms. But you're not forced to use it. When you have still performance issues in your Xamarin.Android or Xamarin.iOS app then you produce them in your code.
There are benchmark results for Android apps comparing Xamarin.Android and Java apps: Does anyone have benchmarks (code & results) comparing performance of Android apps written in Xamarin C# and Java?
As you can see Xamarin's internal performance became better and better over the time.
Conclusion: Yes, you can write smooth native Apps using Xamarin.

Windows Phone 7 Samples

What Windows Phone 7 demo/reference applications have you seen which really made you interested in developing for the platform?
I know of Scott Gu's Twitter example and Foursquare. Also see here for MIX10 demo apps.
Other than developing games and re-creating functionality already present on other mobile platforms (iPhone, BlackBerry, Android), is there any good reference material and business benefits of developing for Windows Phone 7? Does the Silverlight dev environment really offer an advantage over what is already out there? My gut feeling is that this is definitely the case, but it will take some time for the platform to establish itself, if it does.
You can find a lot of examples and reference applications here www.reddit.com/r/wp7dev/ or search using the hashtag #wp7dev on twitter (full disclosure - some of my examples appear there).
There a examples of what people are openly working on, but one can assume it is a lot more - hopefully this is useful, as it shows what can be done, or is being done on the platform.
As a novice developer, other phone platforms came with a lot of overhead required to build even the simplest application. The fact that XNA will be available for game development is a huge thing for me, it means I can create simple games for me and my friends without having to spend time learning a new language or setting up awkward SDK's and deployment settings.
More advanced developers may scoff at that, but development tools that are already being used that can work right out of the box for the intended platform is important for the hobbyists. I think this will open up a huge arena for homemade games and apps just like XNA did for 360 development.
It should also help sales. I will buy a Windows 7 phone because of this, and I can imagine others will do the same. As it stands, I am going to port my existing XNA games over so I can play them on the go. It will be cool to show people at the office, airport, etc. projects I have made right on the spot, and even give them the option to play if they have the right hardware.

Resources