search

openhab / openhab-ios

The repository of the iOS client
Eclipse Public License 2.0
185 stars 126 forks source link

Plan for new App Release #756

Open digitaldan opened 1 month ago

digitaldan commented 1 month 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 1 month 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 1 month 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 1 month 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 1 month 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 1 month ago

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

digitaldan commented 1 month 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 1 month 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 1 month 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 1 month 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 1 month 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 1 month 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 1 month 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 4 weeks 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 4 weeks ago

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

digitaldan commented 4 weeks 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 4 weeks 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 3 weeks 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 3 weeks 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 3 weeks 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 2 weeks 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 2 weeks 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 2 weeks ago

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

hmerk commented 2 weeks 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 5 days 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 3 days 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 1 day 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.