Question about customizing SpeziTemplateApplication

[hafrfr]

What Stanford Spezi module is your challenge related to?

SpeziTemplateApplication

Description

Hello everyone!

Harald from Chalmers here! I hope you all are doing good :)

I’ve been exploring the SpeziTemplateApplication a bit and I think I'm starting to get a feel for how things are structured.

I have started looking into modifying the actual modules, but before diving into specifics on the modules — is there any recommended way to expand or replace parts of the template without causing conflicts or “duplicate definition” issues? I am completely new to Xcode/Swift, so I copied a module but that seemed to cause distruptions. Therefore I wanted to look into "best practice" around this. Should we be removing your modules as we expand, replacing them with our custom modules, or are there other ways to go about it?

Just want to make sure we build on top of things in a clean way before we go too far, as we haven't even received our project yet!

Thank you guys :) love the structure and design of the framework so far!

Reproduction

Expected behavior

Additional context

No response

Code of Conduct

• I agree to follow this projects's Code of Conduct and Contributing Guidelines

[PSchmiedmayer]

Great question, @hafrfr! I'm excited to see that you tested out the template application!

I would suggest seeing the Spezi Modules as building blocks that you can add and remove as needed. If you observe that a module is not a right fit for your application (e.g., you never will use questionnaires, and therefore, it makes sense to remove SpeziQuestinnaire), that's the best way to go. If you want to, e.g., use LLMs in your app, maybe check out SpeziLLM and see if it would be a good fit.

The idea behind the Spezi modules is that they offer certain modification possibilities using their public APIs. For example, let's say you want to collect different HealthKit data types than the ones listed in the template application. You can use the SpeziHealthKit configuration to modify this behavior of the module or even use some of the additional functionality that SpeziHealthKit provides including nice ways to query specific data in the user interface or display charts that display HealthKit metrics. All Spezi Modules offer a decent amount of APIs (and documentation) that allow you to customize them or use additional functionality in the app; those might be the first areas where I would suggest looking into before you aim to completely modify the module or copy code out of the modules in your app.

In general, developers use core SwiftUI principles and code that is written within the dedicated applications to build new views, remove elements that are not needed, and extend the functionality on top of the existing foundations found in the template app.

Last but not least: You can, of course, also always fork an existing module (they are all just GitHub repos) and make modifications to it there if you come to the conclusion that the module is missing any functionality; there is no adequate extension point, or there is a bug in there that you would like to contribute back to the upstream module. This might be the last resort if you observe that the module contains valuable code but is not fit for your app, and you would need to modify elements right there.

[hafrfr]

Here’s the TestFlight link as promised:
TestFlight Link

You’ll also see a short "What to Test" and app description inside TestFlight itself to make everything easy to navigate.
Small dev tip: you can triple tap the progress bar inside the Schedule view if you want to replay the onboarding at any time.

Looking forward to hearing any thoughts you might have!

[PSchmiedmayer]

Very cool; just downloaded the app & went though some of the screens. Nice job; even works quite well on a Mac! 🚀

[hafrfr]

Quick update: v3 is almost ready – where we have worked hard to incorporate our ambitions and accomodate tester feedback. It's the final version before our presentation next week!

Trying to distribute the build, but hitting a validation error due to background processing (see screenshot below). I added this to Info.plist as a potential solution:

BGTaskSchedulerPermittedIdentifiers

com.chalmers.digitalhealth.opatbackgroundtask

Think that’ll do it? Or should we just remove processing if it’s not a major component of this prototype?
Just out of curiosity – what do you think is the reason for this error showing up now, when we were able to use background processing for v2 without issues?

Appreciate any quick advice – then we’re live with the v3 update for you guys!

[hafrfr]

Follow-up – the fix worked! App passed validation after updating the Info.plist, so no need to remove background processing for now. But definitely let me know if you’d suggest a better approach or if my fix might cause issues long-term.

We’re now just waiting for the TestFlight review to go through – once it does, v3 will be live and you’ll be able to update the app and explore right away!

Really excited to hear what you think about v3!

[PSchmiedmayer]

Thank you for working on all of this @hafrfr!
The error might have only surfaced as Apple sometimes updates their App Store connect setup to add more sophisticated checks; might be on of these things or some dependency or update has added some additional calls that triggered this error message. Your approach is right; adding the background task identifier is the way to go; you don't currently use the value so your value makes sense.