search

openhab / openhab-ios

The repository of the iOS client
Eclipse Public License 2.0
193 stars 128 forks source link

Plan for new App Release #756

Closed digitaldan closed 2 months ago

digitaldan commented 5 months ago

Here's the latest news from Apple. I spoke with a developer support rep on Friday after months of back and forth emails. Basically, our watch ID has been claimed by another developer account, and they won't tell us who that is or reclaim it for us. Because of this, we can no longer push our app with watchkit support any longer as that ID can not be changed once published in the app store. This seems to be confusing to Apple as well as we have gone through several back and forth with tickets escalated to their dev team.

Our case is still open and i sent a fresh batch of error logs to them after trying a few changes they recommended, but i have little to no confidence now that Apple is going to be able to help.

My suggestion is that we publish this as a new app and new app ID into the app store. I would also like to then push an update to our existing app that will direct users to download the new app, maybe a simple popup that gets triggered at launch stating the issue.

see #746 for more history on this

Todo Items

openHAB legacy changes

Deployment Todo

We need to work out timing. Ideally we would get the new app approved and published before renaming the current app and pushing an update to it. But we also don't want to be rejected by submitting an app first with the same name and icon (although i have seen this with other companies like solaredge who had two apps for a while)

digitaldan commented 5 months ago

@timbms @weakfl Thoughts on the plan? Specifically to get started i think we need to agree on a 1) branching strategy (create openhab-legacy from either main or develop), and 2) if we want to operate on main and do away with develop ( matching openhab-core, openhab-addons, openhab-js, etc....)

From there i think we can start assigning tasks, i can handle the FCM changes and can update the legacy app with new logos, name, remove watchkit, and add the popup to start.

I'm kinda partial to merging develop into main as a first step, then branch that for openhab-legacy, and release the legacy app with the latest changes since we have had those thoroughly tested on test flight.

digitaldan commented 5 months ago

Here's an example of another app that renamed theirs "legacy", so at least there is precedence for this.

https://apps.apple.com/us/app/play-legacy-app/id1479709805

timbms commented 5 months ago

I'm kinda partial to merging develop into main as a first step, then branch that for openhab-legacy, and release the legacy app with the latest changes since we have had those thoroughly tested on test flight.

The actual development was on 'develop'. Therefore we should branch 'openhab-legacy' from develop. 'main' was not used recently for development. I don't know how much effort it will be to bring 'develop' to 'main'.

digitaldan commented 5 months ago

I started to merge develop into main, which was fine, but since we don't really use it, i just renamed to main-old for the time being (we can probably safely delete). I suggest we now rename develop -> main and use that going forward. I'll also branch for the legacy app from that.

digitaldan commented 5 months ago

openhab legacy branch from develop https://github.com/openhab/openhab-ios/tree/openhab-legacy

digitaldan commented 5 months ago

Does anyone have any experience with the privacy file @weakfl mentioned? I'm reading about it, and besides making sure our 3rd party libraries are updated and have this file, i'm not sure that we actually access or collect anything that needs to be declared? We do access UserDefaults , not sure if that counts as a privacy API?

EDIT: see #757

digitaldan commented 5 months ago

Moving right along. Now that the privacy policy and messaging changes are in, i think its time to start working on the two different apps and ids. For our new build, shall we go with org.openhab.moblie or org.openhab.ios or org.openhab.ui ? I was thinking about how universal builds work and that you can target the Mac Desktop, Apple TV, Carplay, etc.... with a single App ID, which is giving me a little pause on the bundle ID naming (like should we use mobile or ios in the name when it can run on other platforms).

Thoughts?

florian-h05 commented 5 months ago

Just giving my two cents to this discussion without being an iOS app developer:

org.openhab.ui would be the bet of these IMO, your reasoning sounds well. However does it remind me of the Main UI bundle …

Would something like org.openhab.apple be allowed? Also putting org.openhab.darwin on the list, because all Apple OSes have something in common: the Darwin kernel.

digitaldan commented 5 months ago

Thanks @florian-h05! There's an old (ish) saying in computer science:

There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.

Naming things is hard ;-) Using darwin is an interesting thought, although i wonder if thats kinda implied just by being in the apple app store.

I was looking around for some inspiration, Sonos uses com.sonos.SonosController and com.sonos.SonosController2, they also have a legacy app and then a new one (named S1 and S2). I was thinking about it more, and org.openhab.controller might be a good choice too? I guess if there are no other opinions i can just pick something by the end of the day. We can always change it right up to the point we release the app publicly.

I guess in the end its not super important, i just know once we publish its set in stone this time.

weakfl commented 5 months ago

Throwing my hat in the ring with org.openhab.apple.app.

In the end it wont matter much, no one ever sees the bundle id anyway.

SKU is harder imho 😂

digitaldan commented 5 months ago

How about just org.openhab.app , since the apple part is probably implied by being an apple ID? I'm good with that.

digitaldan commented 5 months ago

So openHAB Legacy does not fit well as a bundle display name, IOS is removing the space to try and get it to fit:

image

What about use something like openHAB V1 ?

image
digitaldan commented 5 months ago

@timbms and @weakfl looks like there are a few pull requests that add new features, or require the new SDK versions. How shall we handle those? I'm probably going to run out of time this weekend to do much else, but i will try and get some dev time in later in the week.

My next steps are to work on the legacy app and add an upgrade UI to it as well as change the logo slightly to differentiate from the main app.

timbms commented 5 months ago

Yes I wrote some of them. I wished we could at least upgrade to SwiftUI watch app

digitaldan commented 5 months ago

I wished we could at least upgrade to SwiftUI watch app

I'm not super familiar with SwiftUI, is there a reason we can't ?

Also i was looking at IOS SDK compatibility and it seems like IOS 15 is really the floor, IOS 14 does not seem to be a max version for any device, see https://iosref.com/ios . Should we set the min SDK version to 15 ?

weakfl commented 5 months ago

Apple's recommendation is current and previous version, so that would be iOS 16.

Would be really beneficial for SwiftUI as well.

digitaldan commented 5 months ago

So i think IOS 16 sounds like a good base version to me , i guess this will be one advantage of having two apps, we can keep the current target with the legacy app for those with older devices.

weakfl commented 5 months ago

iOS 16 would be great.

We just need to make sure to also adapt swiftlint/swiftformat configs (and swift-version).

That will help to catch all sorts of obsolete availability checks and update swift syntax to the latest version.

digitaldan commented 5 months ago

So i was thinking about something like this to message users to upgrade to the new app. Needs some UI formatting and cleanup, but you get the idea. I was thinking this would display when the app is launched, and is also available in the settings menu. The user has the option of not being reminded before dismissing.

image
hmerk commented 5 months ago

Just to add my 2 cents. Raising minimum Level to iOS 16 will stop many devices to be usable. Our Democase e.g. has a built in iPad stuck at iOS 15.x and we would need to buy a new one, just for going on conferences a couple of times a year. Not only me, but some users have older devices mounted as wall displays. We would force them to buy newer hardware....

timbms commented 5 months ago

sure. Old devices can stay on legacy app. iOS 16 runs on iPhone 8 and iPadOS 16 runs on iPad 5th generation from 2017.

weakfl commented 5 months ago

iOS 16/17 covers 96% of users. This will further increase with the release of iOS 18.

hmerk commented 5 months ago

sure. Old devices can stay on legacy app. iOS 16 runs on iPhone 8 and iPadOS 16 runs on iPad 5th generation from 2017.

Ok, absolutely forgot this option ;-)

lsiepel commented 4 months ago

Unfortunately I cannot add much to this discussion, app development is not my expertise. But if I can support or move this forward in any way, let me know. I would really like to have this app updated with the slider fix 👍

digitaldan commented 4 months ago

@weakfl @timbms , i am thinking through what needs to be done to prepare for publishing the 2 apps. Would appreciate some help here on what needs to be changed.

App Store Connect Tasks (Manually configuring on https://appstoreconnect.apple.com)

Fastlane Changes

Github Actions

Let me know what you think , I'm hoping to update the legacy images this week.

digitaldan commented 4 months ago

So i have changed the app on apple connect to openHAB V1 and also created a new app, openHAB V2. As soon as V1 publishes , i can change the name of the V2 app to just openHAB . Right now it won't let me since our published app is using that name.

digitaldan commented 4 months ago

@weakfl i'm having a wee bit of trouble with fastlane.

First is just getting it running again with github actions for testflight builds.

Second, I am manually submitting builds until we can get it automated, but i was still hoping to use fastlane locally to generate screenshots for the app store. Thats still not working for me as much as i have tried. If you could help me fix that so i can at least run it locally, would be a big help.

weakfl commented 4 months ago

@digitaldan I'll take a look in the coming days.

digitaldan commented 4 months ago

Thanks @weakfl !!!!

weakfl commented 4 months ago

@digitaldan ci builds are fixed in #781 (legacy app) and #782 (new app).

However, I have noticed that the version of the new app is set to 1.0.0. I'm afraid this might mislead some users to believe that the legacy app is more recent than the new app.

I'd rather start with a higher version, maybe 2.5.0 or even 3.0.0.

Thoughts @digitaldan @timbms?

weakfl commented 4 months ago

@digitaldan screenshots lane is fixed in #782 as well

digitaldan commented 4 months ago

@weakfl wow! , thanks for fixing that, was driving me nuts trying to debug, and was not looking forward to having to try and do screenshots by hand. Thats a huge help.

I'd rather start with a higher version, maybe 2.5.0 or even 3.0.0.

yeah, i was also debating 1 or 3 , so i vote we go with 3.0.0

curlyel commented 4 months ago

Sure, other topics deserve more attention to get the updated app through the door... ;-)

Though: Any plans for multiple instance support (https://github.com/openhab/openhab-ios/issues/557) similar to the Android app?

digitaldan commented 4 months ago

You can vote for it over there, but thats off topic from what this ticket is trying to coordinate. Please move discussion of feature requests to their own tickets.

florian-h05 commented 4 months ago

@digitaldan Media attachment support for openHAB Items is broken for me since version 3.0.1 (5) - it works with 1.0.0 (3) but does not work with newer TestFlight versions.

digitaldan commented 4 months ago

Its still working for me, what are you using for the media attachment URL ?

digitaldan commented 4 months ago

also you should be on 3.0.3(7), yes?

florian-h05 commented 4 months ago

I am using item:Doorbell_Image. I was on 3.0.3 (7) but downgraded due to this issue.

digitaldan commented 4 months ago

Ah, your right, not sure how i missed that, give me a few and i'll push a new release, probably a small thing from refactoring the HTTP client.

digitaldan commented 4 months ago

Actually i take that back, the image item i quickly tested with had a null state. Is there anything different about your setup, i think you are using client based certs ?

florian-h05 commented 4 months ago

Yeah, I am using client cert auth, but if I disable wifi on my phone, openHAB cloud should be used and it also doesn't work there.

digitaldan commented 4 months ago

So i can confirm the the client certs are not working (they were at one point) with the new http client code, so thats something. I'll play around more with that tonight and double check the cloud connection logic.

digitaldan commented 4 months ago

@florian-h05 i have a fix, was banging my head a bit until i realized the notification extension was not using the same keychain as the main app, keychain sharing has to be explicitly enabled through entitlements. Working now, i'll merge shortly and a testflight build will follow.

digitaldan commented 4 months ago

@florian-h05 let me know if the latest testflight works for you.

florian-h05 commented 4 months ago

Just tested it - works again. Thanks!

alaub81 commented 4 months ago

I've installed the latest TestFlight version and everything works fine! Thanks for the great work!!!

Just a question, The icons on the watch are not shown. Because the fix for #748 isn't included in the current TestFlight version?

hmerk commented 4 months ago

And it's not possible to add the app as a complication on apple watch

Why not ? image

image

hmerk commented 4 months ago

But it is shown under installed Apps?

lsiepel commented 3 months ago

Are we ready to submit the new release for review? Or do we need some more work before we can?

florian-h05 commented 2 months ago

What’s the status here?