Reposting this AMA question here because I think it is very important.
I struggle to find definitive and concice guidance on when to use PowerApps over traditional developed apps. I totally get the target audience for PowerApps as non traditional developers making LOB apps, etc. But when trying to forecast if to go with a PowerApps solution over traditional development, I find the info lacking.
What are the obvious indicators that PowerApps wouldn't work over traditional apps? I.e.:
Go with traditional apps if you need:
Go with power apps if you need
Can anyone help me clarify which approach would be best to take?
@audrieg had replied with this:
This is an awesome question! We are working on developing a diagram inline with this question which would include common development comparisons.
In the meantime, we can say that a key factor between UWP is that it is for the Windows platform, whereas PowerApps is cross platform by design (covering iOS and Android for example).
Stand by for more information that will help decision makers on the community blog soon!
(and to continue to conversation).
I guess my original subject and question were poorly worded, (specific to UWP). MS provides developers with Xamarin which allows us to target xplat for Android and iOS. Aside from that benefit from PowerApps, what else would make the decision easier to make?
Yes, I did read your question more broadly, and especially liked the way you asked it. Bullet points for when to go with traditional apps, and when to go with PowerApps, is a great idea and is targeted for an upcoming blog post.
I agree that clarifying that will be helpful to anyone who is considering PowerApps.
I tend to head for PowerApps when I'm looking for organizational engagement from Information Workers. For example, where I want my org to provide me with information, or give them easy access to view information. So, one of the areas I might head for other options is when anonymous access to the app is required - such as for public portals.
With that thought in mind, I would like to break this down into "business drivers" and "technical drivers" to provide you with a more complete answer with the team's input as well..... so I'm asking for your patience on the blog topic. 🙂
Thank you for posting this important question! We are totally on it!
In the meantime, check out this presentation from the Microsoft Ignite conference which dives into the many of the "whys" related to choosing PowerApps:
Use traditional pro dev tools and SDKs if you need:
Use PowerApps if you need:
Thanks for the reply.
I think another question on traditional developer's minds would be "is there any middle ground?", That is, can we use PowerApps and get all of the benefits from it, but use traditional development tools? I don't think many developers would be excited to see the Fx bar and we know that the experience is targeted for non-developers. But is there an SDK (C#?) that we could tap into to develop in a familar way?
I know we can leverage Managed APIs and other backend services that we can create using our known tech stack, but what about the "app" itself?
The bridge between the app itself and developer value add resides in a combination of things....but to answer briefly I would focus on these two opportunities:
1. Swagger / APIs
2. Azure Functions (great article by Carlos....who I expect we will hear more from on developer opportunities)
I've been building use cases for these approaches, but I'm sure they are not a full picture of what is possible.
Does that answer that part of your question more directly?
My question was more on the developing of the app rather than the integrations.
Simply put, can we use C# instead of the "excel like formulas" to define our logic?
(Think how (now defunct) LightSwitch was used)
No. That is not available at this time. Although, I do not believe it would be necessary for you to add a lot of value in one of the other ways above.
Check out these videos to see what I mean:
Please also share your use cases on the PowerApps Idea board here:
Nice post. Looking forward to blog and expanded 'middle-ground' opportunities.
Audrie, Regarding the middle ground, you mention Custom APIs. The problem is that there is no guidance on how to develop a custom api which exposes what PA considers a 'tabular' datasource. I need my custom API to expose the design-time tooling in PA for named entities and forms controls exactly like the SQL Connector does. How do I do that?
please see these...
ideas without response:
PS...FWIW, since the OP mentioned LightSwitch, PowerApps isn't even remotely considerable as an alternative to LightSwitch without the ability to create Custom APIs having 'tabular' design-time capabilities. Even with that PA might be usable for a very small subset of LS capabilities.
Fill out a quick form to claim your user group badge now!
Find out where you can attend!
Features releasing from October 2019 through March 2020
Learn how to build the business apps that you need.