OEP-64 Mobile Application Codebase Modernization

[marcotuts]

Opening this OEP draft for community review and input.

Abstract
As part of the discovery effort done for a funded contribution (FC-0011) we are recommending that the Open edX platform adopt newly built iOS and Android applications as the new default mobile applications for the platform moving forward, starting with the next named release. These new applications are rebuilt with MVVM architectural patterns and are fully rebuilt in Swift and Kotlin respectively. These new code bases should facilitate faster development cycles, improved pluggability and community contribution rates. Currently not all functionality is 100% identical to the existing mobile applications, but efforts are underway to improve pluggability and close common community requirements for the mobile experience.

The new mobile repositories are maintained by Raccoon Gang and can be accessed here:

• https://github.com/raccoongang/educationx-app-ios
• https://github.com/raccoongang/educationx-app-android

The existing mobile repositories are maintained by edX / 2U and can be accessed here:

• https://github.com/openedx/edx-app-ios
• https://github.com/openedx/edx-app-android

FYi @colinbrash, @e0d

[openedx-webhooks]

Thanks for the pull request, @marcotuts! Please note that it may take us up to several weeks or months to complete a review and merge your PR.

Feel free to add as much of the following information to the ticket as you can:

• supporting documentation
• Open edX discussion forum threads
• timeline information ("this must be merged by XX date", and why that is)
• partner information ("this is a course on edx.org")
• any other information that can help Product understand the context for the PR

All technical communication about the code itself will be done via the GitHub pull request interface. As a reminder, our process documentation is here.

Please let us know once your PR is ready for our review and all tests are green.

[sarina]

@marcotuts Redwood!

[e0d]

I notice there are some commit-lint failures. Please note that we use conventional commits across Open edX projects. You can read about the details here. Can you please amend your commit messages to follow our standard?

[e0d]

Can someone from 2U confirm and/or clarify this? Also, support in this context is not well defined as far as I know. Is there any working definition?

[sarina]

What is the aim in including this section?

[marcotuts]

We dont actually know who else in the community is using the existing apps, this note was meant to convey continued support for these applications until edx / 2U decides to move to the new applications

I can strike if this concern doesn't feel core to what the OEP should be covering though!

[sarina]

I think I understand the point, but as-written it feels too "point in time" - OEPs should be lasting documents. At minimum I would strike the point about commerce capabilities because I doubt edX/2U is planning to support that for the community.

[marcotuts]

makes sense! updating. thanks for feedback on this.

[sarina]

The title of this file should be oep-0064-arch-mobile... - see convention here: https://github.com/openedx/open-edx-proposals/tree/master/oeps/architectural-decisions

[sarina]

What is the aim in including this section?

[felipemontoya]

There are some form issues that need to be fixed but I'm very supportive of the goal of this OEP. I'll leave an approve now since I could not catch any other inline corrections other than those already mentioned.

[adamstankiewicz]

[inform/question] Related to the mention of design system tools, just wanted to cross-link to this Paragon issue about mobile app branding as it relates to Paragon design tokens.

That is, there may be an opportunity to treat the Paragon design system as the "source of truth" for style properties like colors, typography, etc. across both web and mobile native platforms, as is the longer term vision for the Paragon design system.

The Paragon Working Group is currently working towards migrating the Open edX web-based experiences (MFEs) to use design tokens and CSS variables. I don't think it'd be a unreasonable lift to get Paragon design tokens transformed into iOS/Android compatible output that can be consumed by mobile apps. That way, when a style property in the design system changes, its update can more readily propagate across cross-platform with less maintenance required.

Do you think it's worth expanding on how design system tools (e.g., design tokens) could play a role here, or is that too "in the weeds" for the purpose of this OEP?

[marcotuts]

Good question I think adding that detail might be in the weeds for the scope of the OEP but the issue in paragon that Ed created is a space we can continue the conversation toward the goal you described of a single source of truth for that kind of design meta.

Others can chime in if they feel like additional detail should be added. Thanks for reviewing!

[adamstankiewicz]

Makes sense, sounds good!

[kdmccormick]

@adamstankiewicz @marcotuts @volodymyr.chekyrta Non-blocking, but even as someone who is mostly out of the loop on MFEs and the mobile apps, I have the impression that Open edX's move towards Paragon design tokens is pivotal in terms of re-establishing a consistent branding interface for the project. Confusion around theming & branding is consistently identified as one of operators' major pain points ever since we started phasing out comprehensive theming.

What do you folks think of a high-level statement in the OEP stating the design tokens (or something like it) will be supported? For example:

In support of a consistent platform-wide branding interface, the experiences will implement branding via Paragon design tokens once tooling for the tokens reaches maturity.

or, to be more general:

The experiences will strive to support a branding interface consistent with other Open edX frontend applications based on recommendations from the Frontend and Paragon Working Groups.

[adamstankiewicz]

Confusion around theming & branding is consistently identified as one of operators' major pain points ever since we started phasing out comprehensive theming.

@kdmccormick Definitely. I think aligning on how we communicate about Paragon could help begin to mitigate this confusion. For example, perhaps rather than saying "theme-ready" and other "theming" related messaging throughout the documentation, we could adopt "brand-ready" and "branding", as an incremental step:

"An accessible, theme-ready brand-ready, and open source design system built for learning applications."

(from docs site)

[adamstankiewicz]

What do you folks think of a high-level statement in the OEP stating the design tokens (or something like it) will be supported?

@kdmccormick @marcotuts @volodymyr-chekyrta I would be in favor of including an explicit albeit brief, high-level mention of the design system (also, not blocking feedback though 😄). Perhaps a blend of your two suggestions, Kyle. E.g. something along the lines of:

In support of a consistent platform-wide branding interface, the mobile experiences will strive to identify opportunities to consume and extend the Paragon design system, helping to ensure consistent and maintainable UX across channels (i.e., mobile, web).

[marcotuts]

adding in next commit / update - thank you for the thoughtful inclusion and deliberation on this point!

[kdmccormick]

Looks great. Very excited for this! 🚀

Just one non-blocking comment on design tokens.

[kdmccormick]

@adamstankiewicz @marcotuts @volodymyr.chekyrta Non-blocking, but even as someone who is mostly out of the loop on MFEs and the mobile apps, I have the impression that Open edX's move towards Paragon design tokens is pivotal in terms of re-establishing a consistent branding interface for the project. Confusion around theming & branding is consistently identified as one of operators' major pain points ever since we started phasing out comprehensive theming.

What do you folks think of a high-level statement in the OEP stating the design tokens (or something like it) will be supported? For example:

In support of a consistent platform-wide branding interface, the experiences will implement branding via Paragon design tokens once tooling for the tokens reaches maturity.

or, to be more general:

The experiences will strive to support a branding interface consistent with other Open edX frontend applications based on recommendations from the Frontend and Paragon Working Groups.

[adamstankiewicz]

[curious/clarification] What other technologies/architectural patterns were considered beyond Swift and Kotlin?

For example, was React Native explored? While I personally don't have much experience with React Native, I believe one of its primary goals is to enable a "write one, use everywhere" approach where possible, enabling sharing of code across platforms (even between web + mobile). One might hypothesize having shared code across iOS, Android, and web could lead to having the mobile apps be more approachable/maintainable by the community, align closer to other React-based UI development in the Open edX platform (i.e., micro-frontends), etc.

More specifically, I'd be curious whether something like React Native could enable sharing of existing styles/patterns/functionality in the Paragon design system. For example, could common UI patterns across both web and mobile both live under the same Paragon design system, but ship with and get consumed via different implementations (React Native for mobile vs. React for web)? Food for thought; felt appropriate to expand a bit more on the technology choices.

[marcotuts]

Hi!

We did not do a deep dive into React Native in advance of this effort, but have received similar questions about this and Flutter ( https://flutter.dev/).

Currently, the belief from the team is that the benefits of native Swift + Kotlin development fit to OS purpose is preferred over the benefits of shared code bases. A number of other companies have posted articles on their adoption of React Native and subsequent decisions to switch back to native development.

As with anything there are likely happy companies and teams on boths sides of this, but we've chosen to stay on the native path for now.

[scottrish]

@marcotuts As the mobile apps are distributed as binaries via the respective app stores, I don't believe AGPL is the appropriate license to apply. Can we adopt GPL-V3 instead?

[e0d]

@marcotuts As the mobile apps are distributed as binaries via the respective app stores, I don't believe AGPL is the appropriate license to apply. Can we adopt GPL-V3 instead?

Apache2 has been the license under which our mobile applications have been offered historically. It's a project approved license and appropriate for this case. My recommendation is that we re-license these applications to Apache2.

Changes have been addressed according to e0d but sarina is not able to re-review.

[openedx-webhooks]

@marcotuts 🎉 Your pull request was merged! Please take a moment to answer a two question survey so we can improve your experience in the future.

[kdmccormick]

@marcotuts or @e0d, can you review the formatting of this section? I would suggest a fix ,but I'm not sure if this is meant to be one bullet list or multiple.

Here's how it currently renders: https://open-edx-proposals--496.org.readthedocs.build/en/496/architectural-decisions/oep-0064-arch-mobile-application-codebase-modernization.html

[marcotuts]

Thanks for flagging Kyle, I didn't notice this so at some point I must have broken this. I can open a new PR for formatting fixes to this.