What happens when I increase "minApiLevel" and deploy updates?

Hi All,

Thanks for being so quick & helpful with all my questions getting started in the community. I've now got a few WFs in the CIQ Store, and I'm planning an update to all of them to include System 6 features. That means updating my "minApiLevel" for the first time and then re-deploying. I've never done this before, and I couldn't find any documentation / posts about the customer experience after I publish an update like this.

For users/customers that are on devices that aren't yet updated to System 6:

Will new customers still see my WF listing, even if their device isn't updated to support it? If they try to install, what happens?
What's the process like for existing customers who already have the WF installed?

Thanks!

-Mike

Top Replies

All Replies

0 Shent-Aurkhan (SHN) over 2 years ago

hi, don't touch the "minApiLevel", if you do so, some user won't have your WF anymore.

just includ in your manifest the new devices and put some has check for new functions or use jungle.

0 flocsy🤠 over 2 years ago

I think the question is still valid. In my case i am planning to add app trials, which means that older watches that are supported by the current version (let's call it 1.0) will need to be removed from the manifest because they crash when appTrials is added to the manifest. So if I'll update to 2.0, then will the old devices still be able to find, install version 1.0? I guess the answer is no, but maybe someone already tried this.

0 jim_m_58 over 2 years ago in reply to Shent-Aurkhan (SHN)

This is exactly how I do it. My minApiLevel is 1.2.x for all apps, and between "has" and jungles, I can run on all devices even if the app can publish complications (for example)

0 myaro over 2 years ago

Thanks, all. I really appreciate it - that was almost a big mistake by changing the minApiLevel.

I've been trying to keep the build configuration simple & my target audience narrow: high-memory devices (~120K) with round AMOLED screens. So I'm trying to avoid making complex jungles (at least for now). Even still, I have some open questions about what's safe, since I can't seem to find a way to test on a device running < 4.2.

I'm not sure how to test the following questions:

Can I safely add the "ComplicationSubscriber" permission to the manifest for everyone and just ship it? Or is that going to cause problems on devices < 4.2 that don't recognize the new permission? Gavriel seems to suggest it might, given his experience with appTrials.
How can I safely import a Toybox.Complications module if the device doesn't have it? I tried importing "Toybox.Nanobots" to simulate what would happen by importing an unknown module, and it won't even build. So I'm not sure how to simulate what "Complications" would look like on a device running <4.2?

I remembered the SensorHistory documentation had a pattern that used "using Toybox.SensorHistory" and then "Toybox has :SensorHistory". I'm going to try this path and just define a "HAS_COMPLICATIONS" flag based on "Toybox has :Complications", but it feels odd to import something possibly not there.

Also, my prior question on this topic was also a big help (in case anyone stumbles on this by search).
System 6 vs. SDK 4.1.6 vs. Software Version 10.44?: How do they relate?

0 jim_m_58 over 2 years ago in reply to myaro

Think of Complications like SensorHistory. In both cases, they need a permission. And in both cases a device may or may not have that.

In both cases I see a boolean if the app can use them (I only set the boolean in initialize() as "has" is more expensive than just checking a boolean.

So,

hasSH=(Toybox has :SensorHistory);

hasComps=(Toybox has :Complications);

And you want to have the import/using in both cases.

Then use hasSH/hasComps to have your code execute without error.

Here's one of my test watch faces for complications. It's written you use the Steps Complication as well as one I publish from a widget. On a fr955, here's how it looks:

While on a 945, (no complications)

This shows something else - if you want to display something you get from a complication, what do you do if you can't use complications? Something to keep in mind.

It's the same code in both cases, and the differences are is if "hasComps" is true or false.

You are going to want to use the 4.2.2 SDK. I've not tried it, but 4.1.7 may have issues with some things, including the permission for Complications.

Also note that publishing a complication is more complex than this.

0 dpawlyk over 2 years ago in reply to myaro

myaro said:
I've been trying to keep the build configuration simple & my target audience narrow: high-memory devices (~120K) with round AMOLED screens. So I'm trying to avoid making complex jungles (at least for now). Even still, I have some open questions about what's safe, since I can't seem to find a way to test on a device running < 4.2.

It's OK to not support older APIs.

The issue is increasing the API later (since this would lock-out current users).

There can be good reasons not to support older devices. You don't have to support everything.

The "correct" way do do this is have the initial release use a later API and then, if it's appropriate, reduce the API later (to support older devices).

0 jim_m_58 over 2 years ago in reply to dpawlyk

If you don't want to support CIQ 1 or CIQ 2 deices, just remove them as targets vs changing minApiLevel.

0 flocsy🤠 over 2 years ago in reply to jim_m_58

What's the difference? Even when he changes the minApiLevel The compiler won't run until he also removes all the devices that are too old for the new minApiLevel.

0 jim_m_58 over 2 years ago in reply to flocsy🤠

A min api of 3.4 is Sys 6, but 4.0 and 4.1 aren't Sys6.

0 jim_m_58 over 2 years ago in reply to flocsy🤠

If you just remove the target devices, your manifest shows the devices you actually support, and you only see the devices you actually support when testing in the sim.