Signup for the Ionic Newsletter to get the latest news and updates!

  • https://twitter.com/nkellerns fluxx

    F*** Apple. Really. This is such a senseless action against the developer community just to enforce usage of its own tools. I still enjoy Ionic View on Android, but it doesn’t make sense as a tool, now that half of my users cannot access it any more.

    Thanks for developing Ionic View, your efforts in this case and the open communication. Any documentation of already available or future options is welcomed.

    My Questions:

    What does this mean for the Ionic Dev App, it’s still available on the App Store but I don’t understand how it technically differs from the Ionic View App in terms of App Store requirements. Can we rely on the Dev App in the foreseeable future?

    I don’t have an Apple Developer account yet because I mainly use Ionic for mock-up and pre-production apps. I then deployed these apps via Ionic View to a small group of users (< 10 users / app). What would be the next best solution for this use case? Testflight is completely over-sized for this use case, so I guess I have to wrap my head around local IPA deployment in case of iOS?

    In terms of the upcoming article about Testflight (thanks in advance!) I would like to know if I need a Mac to go that way or if I can stay on my Linux / Windows environment.

    • http://mattkremer.com Matt Kremer

      Hey there fluxx!

      For DevApp, we’re honestly not quite sure. We’re just going to have to wait on that one and see what happens.

      If you’d like to do local / cloud IPA deployment, you could package it using Ionic Package, then install it “over a wire” attached to XCode or use a service like Diawi. Option #1 in terms of us moving forward with a sharing feature would most likely entail a feature like Diawi, would that be helpful?

      For TestFlight you’ll definitely need a Mac in order to upload a binary to iTunes Connect 🙁 The good news is that TestFlight releases are good for 90 days, and you can use Ionic Deploy to send updates to them, so you’ll only need to do that once every 90 days if no native changes! More info on that tomorrow.

      • https://twitter.com/nkellerns fluxx

        Thanks Matt. In fact, I would appreciate if all three options are available in the future.

        Right now, a quick way to share apps as PWA would already be sufficient for my current needs and I guess it’s the easiest implementation out of all three. Especially for new developers it’s a quick and easy way for sharing first concepts.

        Testflight looks like the best option from a platform viewpoint, as it’s the native solution and won’t change that quickly. (Who knows how Apple handles directly shared IPAs in the future). But a big plus of frameworks like Ionic is the fact you’re not enforced into a certain development ecosystem, so Testflight might be the best solution but not for everyone.

  • DOM Slatford

    Thank you for updating us on the issue. It’s a real shame.
    Aside from Ionic View we deploy full native binaries pointing to our test environments to get user feedback and acceptance. Currently done by changing the app id so users can have production and beta versions installed side by side. This is still fiddly for us to manage the config changes but works well. We push the binary out to users via Diawi or similar, it would be great to see ionic with the functionality to install from a URL. I guess this would fall into your option 1.

    • http://mattkremer.com Matt Kremer

      A Diawi style feature is definitely the first step towards #1 in terms of the direction we could possibly go there 🙂 When it comes to having side by side versions, would it be cool if you could overwrite / define that app ID when you perform a Package in Pro?

      • DOM Slatford

        That would be amazingly helpful.
        Currently we’ve got gulp tasks to set the App Id and App name (and icons but thats not end of world) that run before we build.
        We’ve got sensitive content that makes training/presenting our live apps impossible, having them side by side gives us this benefit as well as the UAT for new features.

        • http://mattkremer.com Matt Kremer

          Ah interesting, so you set a different icon for each different build so you can tell them apart on the phone, as well?

          • DOM Slatford

            Yes generally we inverse the colors to make it obvious to those of our users that need both.

          • http://mattkremer.com Matt Kremer

            That’s really cool! Thanks for the info, I was definitely thinking about something like this when we were at a big box retailer who had a TON of phones/devices on a table, all with different versions connected to different APIs, and they had to go through each phone to find the version they wanted to share with me. Some combo of Name + App ID + Icon could go a long way.

  • Tom McLellan

    For native, since apps will be going through iTunes Connect / Google Play process at some point, it may be better to double down on option #1 with stronger automation for pushing out beta channel deployments to users who subscribe.

    Would love to see the following:

    1 – Add hooks or
    integration options (Fastlane?) to the Ionic Package process so our IPA
    and APK’s could be automatically submitted to Testflight and Google Play
    alpha without touching xcode or terminal
    2 – Simplify the Ionic deploy process so it’s easier to reason about version #’s

    The background here is that we implemented the “Subscribe to beta” feature based on your Ionic Deploy docs… it generally worked but got confusing if Ionic Deploy could download anything but the latest build on a given branch. (e.g. sometimes we had a fresh Xcode build auto-downloading an outdated Ionic Deploy build… it was a lot of effort to keep track of equivalent/greater/less than version #’s for both iOS and Android).

    For testing we implemented logic to pull down app settings from a central server based on the app id, including a default API endpoint and an optional test environment. On the first page of the app, testers can tap on a link 5 times to unlock the Test environment, etc. There’s a lot of home grown code involved in that approach, but maybe it could be easier with a centralized configuration service as part of Ionic Pro (or maybe it’s just a matter of tutorials).

    Keep up the awesome work! Looking forward to future updates

    • http://mattkremer.com Matt Kremer

      Hey Tom! Thanks for the insights 🙂 I’d love to dive in a little bit further on your setup, shoot me an email at matt[at]ionic[dot]io? Thanks!

  • Ranjit Chittibabu

    Utilizing Sharing in Ionic Package + Deploy with email notifications and feedback would be your best bet because you will re brand ionic view functionality using downloadable link and get incremental feedback from beta testers.Once tested ,we can use the working order ipa or apk and ship it to app stores via itunes /google developer console.I am sure this will improve your product adoption and entice more developers to use ionic.

    • http://mattkremer.com Matt Kremer

      Thanks for the feedback! 🙂

    • Brandon Peterson

      Honestly this was what was needed most anyway with Ionic Package & Deploy – the ability to install from a link. Without the ability to include custom plugins in Ionic View – I was never able to use it anyway – but distributing via links to clients has always worked with full functionality and its easy enough.

      • yesimahuman

        Thanks for the feedback. I agree re: view plugins, so hopefully this will be a net positive in the end!

  • http://www.badpenguin.org/ Antonio Gallo

    Option 1 is what Phonegap already does and that’s why we use it – we just share the qrcode and people install it… however handling provisioning files and certificates for doing such IOS distribution is a nightmare – also they expire yearly ! So, if you can provide a better alternative to Phonegap we will be happy to switch

    • http://mattkremer.com Matt Kremer

      Thanks for the insight, Antonio! At the beginning, our solution would likely be very similar. Is helping handle provisioning what would get you to switch? Any other problems you’re looking to solve?

  • Marc Bornträger

    I would prefer option 3 as it seems like the most long term solution for native apps (option 2 wouldn’t be an option for us at all).

    • http://mattkremer.com Matt Kremer

      Thanks for the feedback, Marc! 🙂

  • Ruben Miquelino

    Option 3. If you could provide a simple interface on Ionic Pro, this would be the best option. And using the platforms own tools would ensure that this is a solid solution, not a workaround or patch.

    • http://mattkremer.com Matt Kremer

      Definitely! Also I think solution #1 is pretty bullet proof too, I don’t see Apple changing how certificates and provisioning profiles work as it’s what fuels their entire “device lockdown” system. I’m happy Apple is starting to open up their APIs 🙂

      • disqus_1iFvt0pMcZ

        I like option 1 because it opens the door to production deployments to both platforms from the ionic dashboard. Building the application on the ionic dashboard, then still having to go find a mac somewhere to actually deploy the iOS app makes little sense for me.

        • http://mattkremer.com Matt Kremer

          Option 1 would indeed allow you to put it on peoples phones with a provisioning profile, but it wouldn’t allow you to submit to the app stores without a Mac. Is that a deal breaker for you?

          • Ruben Miquelino

            We have a Mini Mac just for compiling. But its getting old, and if we don’t update it soon it will be unusable in the future.
            That’s why i like option 3 so much.

          • Heshyo

            But with option #1 for iOS, you need to add the UDID for each device you need, and there’s a limit of 100 iPhones, 100 iPads, … per year, right? Meaning we would be quite limited in the number of testers?

            Or am I missing something?

  • Guido Arata

    Why are you shutting down it arbitrarily even to those that already have it installed?? I can understand you will no longer support it. And because of Apple decision, it will be no longer available on Apple Store and because of your decision on Play Store neither. But I PAY Ionic Pro and its tools, one of these is Ionic View. I have clients usingi my app by Ionic View. No way you shut it down with just 2 months notice. Is that a joke? Or maybe I get it wrong? Cannot believe who has already Ionic View installed and has already been invited to an app will be no longer able to use Ionic View. It must be a joke

    • yesimahuman

      The problem is that the app won’t be available to new users unless they already have it installed. We can’t both support/maintain View while at the same time not being able to support and promote it for our customers. Additionally, while you may be okay with knowing that only those with it installed today can use it going forward, many existing users would find that incredibly confusing and frustrating.

      This decision lets us end all confusion with our existing customers, and re-focus our energy on providing other solutions that are Apple approved going forward. Thank you for understanding

      • Guido Arata

        I don’t care, I paid annual subscription for a stable tool, you cannot just shut it down and say “we cannot maintain it anymore” , I don’t care. If I sell a website and it’s maintenance, and then I decide to start selling apps, if I’m a professional I keep providing support to my website customers. I can decide to stop selling websites, but I must keep providing support, at least for one year. That’s really, really unprofessional. You really must study how Microsoft created the amazing and stable ecosystem they have, and the answer is not changing cards on the table every 6 months. Incredibile guys, unbelievable.

        • yesimahuman

          I understand the frustration. However, we have been receiving a large volume of support requests at users frustrated that they cannot find the app in the App Store. Since the entire purpose of View is to enable app sharing, if it only works on Android, it won’t serve its purpose.

          Based on feedback, we strongly believe only having View on Android would continue to be very confusing for customers and cause more damage than keeping it. Thank you for understanding.

          • Guido Arata

            I’m not asking to keep it available for download. I cannot – really – understand why have you decided to make it stop working to those that already have it installed! Just stop updates, discontinue it, but let it run on devices that already have it installed! Why don’t you stop all Ionic 1 application working as well? If that’s your ool approch to dev community?

          • yesimahuman

            Because View requires pro dashboard functionality that we have to hide because the app is no longer available. It would be hard/pointless to only have that functionality available to those we detect have the app installed. It also requires engineering resources to maintain. All of that is better spent working on a solution like the ones we’ve discussed here.

            Ionic 1 is purely client side, View is not. The comparison isn’t valid here.

            We are working on a better solution, and we hope this is just a temporary issue.

          • Guido Arata

            Let’s take this scenario: I am using a legacy app on my android through ionic view. This app doesn’t require new updates, changes, etc. I just have to keep be able to use it. So you can completely get rid of ionic view from ionic pro dashboard if you want.
            From September I’ll open Ionic View and I will no longer be able to open the app?

          • Shady Boukhary

            Why don’t you build an apk/ipa for the app and use it like a regular app?

          • Guido Arata

            Btw remember that in 3 months there will be a better solution of this better solution. It’s not by releasing always new solutions and fucking up previous ones that you build up a solid development ecosystem. Just my 2 cents

          • yesimahuman

            I understand the frustration. View has been live for years, and Apple forced our hand here. We wish it wasn’t so but we have to move on. I am confident we will have an even better solution for you in the near future.

          • Guido Arata

            Don’t even try to give the swear to Apple, they did a choice and it can cause a reaction. But your reaction is way ways too much, so it became your fault, not apple. And you are still faking to not getting my point in order to avoid to give me a honest reason.
            Not interested at all in your future better solution, just deleted my ionic pro subscription, not interested in work with such a bad approach.

          • yesimahuman

            Sorry to hear that. Hope to have you back once we’ve filled this void with a stronger solution.

      • Guido Arata

        So why the hell are you not blocking Ionic 1 as well? Following you “explanation” it’s no longer supported, so would be confusing! Why the hell you cannot do with ionic view the same you do for no-longer-maintained products: announce that will be no longer supported, use it at your own risk.
        Don’t give me shit, please.

  • Idrees Khan

    typical apple…why you don’t provide solutions such as https://www.diawi.com/

    • http://mattkremer.com Matt Kremer

      That’s part of option 1, and something we’re definitely looking in to! Thanks for the feedback 😄

      • amor enew

        what about something like Firebase test lab?

  • Marcelo Botega

    Thanks for the update on the issue.
    I prefer the option 3.
    Here on the company we already use a solution with jenkins/fastlane/testflight/google beta and we mostly use ionic pro for error tracking and live deploys.
    I think it the best to make an interface on ionic pro and send direct to the native beta prograns (and i can drop the jenkins/fastlane).

    And i have a question, with this decision from apple the live deploys could be affected ?

  • http://www.danielroot.info Daniel Root

    How annoying of Apple, and especially annoying that it’s taken them so long to communicate that change. I think Ionic Pro should offer all 3 solutions. 1 and 3 really could be accomplished by allowing custom fastlane scripts, or at least with toggles and cert storage for enabling those in the Build/Deploy process. One or two steps to either per-device or TestFlight testing would be great! WRT to #2, I would also like to see a doubling-down on PWA. To me, this means A) documenting where native plugins may not be needed – for example, with newer iOS, I am able to build a photo/camera feature in my app with 0 native plugins, and it works both as PWA and native. B) hosting the built PWA version. I’ve been able to work up a local build to publish a PWA for testing, but would rather have it all done through Ionic. Just put the bits out in AWS or Azure storage with a share token or similar.

  • Ryan M

    Seems like #1 would work well for us, as would #3. We’d opt for the route simplest (least number of hoops to jump through) for the customer, even if that means a little more work on our side.

    #2 has little value to us because of the lack of native plugins. Just some more input!

  • Michael Brown

    #1 or #3 work for me, #2 is useless. Not sure which of #1 or #3 is preferred. Need easy way for invited test users to download app on their own without having to come to my office to get it, an easy way for them to share feedback, and error/crash/analytics reporting.

  • TinkTM

    2 cents…
    1st: If the future of Ionic Package & Deploy is going to be set on one container application contains everything, then sure go with that.

  • John Smith

    India Travel Group, a professional travel company provides Corporate tours to India, Group tours to India, India tour packages, Indian holidays, Hotel bookings for India trip, custom tour packages, holiday packages India and MICE services for inbound tours to India. India Travel Group

  • http://nicholls.azurewebsites.net/ Juan David Nicholls

    What? But you can build the Ionic View app as an Enterprise build and create a web page to download that app from Android and iOS, what do you think?