·   ·  53 posts
  •  ·  632 friends

UNA + NEO = PWA & Native Apps

Most users of popular social media platforms, such as Facebook, Instagram, Snapchat, TikTok, Twitter, LinkedIn, and Pinterest, use their mobile apps. The majority of users across each platform access it via a mobile device, ranging from 80% to 98%. At least 70% of active users in professional networks use native apps, while at least 85% of activity in casual networks comes from native apps as well.

Simply put, four out of five users prefer native apps over desktop or even mobile web apps. The native app experience is generally more seamless, intuitive, and fast.

It is only natural to assume that a network that does not offer native apps would struggle to maintain engagement. Often, good content or intriguing ideas may convince someone to join, but to keep them coming back, a social media site needs native apps.

Mobile Apps Options

Generally there are a few ways you can target mobile. All come with pros and cons:

  • Responsive Website. Traditional HTML / CSS pages with some JS sprinkles for interactivity. This approach is simple, SEO-friendly and easy to maintain. On the flip side, pages have to reload full when URLs change and even with aggressive caching browsing exprience can feel “choppy”. Users can instantly tell that it’s a website. Another downside is limited access to device features. The site is confined within a browser. *UNA produces responsive HTML pages dynamically, rendered on server.
  • Single Page Application (SPA). Instead of loading entire new pages from the server every time a user navigates, an SPA loads data in the background and displays it in specific sections of the page without refreshing the whole page. This can make the web app feel more fluid and faster, more like a native desktop or mobile app. Standard SPA rendered within same URL is not SEO-friendly, however and may not be able to handle links sharing very well. An SPA is also confined within a browser. *Out of the box UNA doesn’t work as an SPA.
  • Single Page Application (SPA) with Server-Side Rendering (SSR). Now we have the best of both worlds - the speed and usability of SPAs with the improved initial load time and SEO friendliness of server-rendered applications. With SSR, the initial rendering of the SPA happens on the server. That means when a user first requests the page, the server generates the full HTML for the page and sends that to the browser, just like in a traditional multi-page application. As a result, the page loads faster initially and is more SEO-friendly because search engine bots can see the fully rendered HTML. After this initial load, the SPA takes over and subsequent navigation and interaction happen entirely on the client side without full page reloads. In other words, once the initially server-rendered page has loaded in the client's browser, it becomes an SPA.
  • Progressive Web App (PWA) based on SPA with SSR. PWAs can be loaded in a web browser like any other website but also offer features typically associated with native apps. PWAs can work without an internet connection, or on low-quality networks, by caching important resources and using service workers – scripts that your browser runs in the background separate from a web page. Users can "install" PWAs on their device's home screen, making it easy to access and launch. This does not involve a traditional app store download and installation process but instead is more like creating a bookmark to the web app. PWAs load quickly and provide smooth, app-like interactions. Twitter and Pinterest, for example, offer PWAs as alternatives to their native apps, allowing users to have a full app experience right in their browsers without needing to install anything from an app store. *While you can ship standard UNA website with manifest file to make it PWA-like, it would need a proper SPA/SSR interface to qualify as a proper Progressive Web App.
  • Hybrid Apps. Hybrid applications are essentially web applications packaged into a native wrapper. They are built using HTML, CSS, and JavaScript, then wrapped in a native application using platforms like Cordova or Ionic. This wrapper acts like a bridge between the web application and the native functionalities of the device. Despite being built with web technologies, hybrid apps can still access and use the device's native features like the camera, accelerometer, or push notifications. Unfortunately, Hybrid apps typically don't perform as well as native apps because they need to go through an extra layer (the webview in the native wrapper) to access the device's features. The difference is subtle, but in the very competitive world of social apps a slight lag in interactions may create that dreaded “sluggish” feel and detract users. Simply put, they might not feel as smooth or "native" as apps built with platform-specific languages and UI components. *Currently UNA comes with a simple React-Native wrapper, effectively allowing you to compile a native app that displays content within web-view.
  • Native Apps - Swift / Kotlin. Native apps are written in languages that the platform they are being built for accepts. For instance, Swift and Objective-C for native iOS apps, Java or Kotlin for native Android apps. Native apps are very fast and responsive, providing the best user experience because they are specifically designed and optimized for a single platform. The layout, interactions, and gestures will all follow the standards of the platform, making the app intuitive for users. Native apps can be distributed through the platform’s app store (like the Apple App Store or Google Play Store), which provides a trusted environment for users to find and install apps. The main downside is that developing native apps can be more time-consuming and expensive than other types of apps because you need to create separate apps for each platform (for example, an iOS version and an Android version) as well as your web version if you want to build a social network where people shoudl be able to open links even if they don’t have an app installed, or if you rely on organic search engine traffic. Typical cost of development of native iOS and Android apps for preconfigured UNA backend is in the range of $150,000-250,000 and any significant changes in backend configuration would likely require relatively large updates.
  • Native Apps - React Native. Unlike traditional mobile development where you would need to write separate code in different languages, React Native allows you to write your code once in JavaScript and it runs on both Android and iOS. Despite being written in JavaScript, React Native applications use native components. This is a departure from other methods of cross-platform development that create "hybrid" apps, which are essentially web apps running inside a native web view container. Because React Native apps use actual native components, they have the look, feel, and performance characteristics of a native app. Examples of apps built with React Native include Facebook, Instagram, Airbnb, and many others.

The Best Choice for Web App

If you want to provide the best possible experience on the web without any compromises, then the optimal choice is a Progressive Web App (PWA) based on a Single Page Application (SPA) with Server-Side Rendering (SSR). This is the pinnacle of web development. Direct access through a browser would lead to a fast, yet SEO-friendly website that can be added to a mobile or desktop device as a progressive app.

There are many frameworks for building SPAs, and some of them support SSR. However, React is by far the most widely used, with a strong community, an extensive ecosystem of components, and a consistent track record in production. For SSR, SSG, and routing, Next.js is a meta-framework that is not only the most popular within the React world but also highly regarded as a fast, well-funded, and production-tested solution.

The Winner: PWA (React.js + Next.js/SSR/SSG)

The Best Choice for Native App

Hybrid apps once had a decent chance due to their ease of updating - simply update the site and the app does the same thing. However, Apple has become more selective with hybrid apps, often refusing to approve them due to lack of added value compared to a website. Moreover, hybrid apps never lived up to user experience expectations - native apps are just smoother.

Now, choosing between React Native and Swift/Kotlin-native is a bit harder. Development in dedicated native languages may potentially produce better-performing apps, but the cost of such an undertaking is at least double that of doing it in React Native. Not only does it require engineers with different skill sets for each app, but you would likely need to consider design and login differences across both iOS and Android native UI elements.

On the other hand, using React Native allows some of the code from your React PWA to be reused, and the app is written in JavaScript (or TypeScript). Maintaining design language across web and native is also much more consistent.

With the Expo framework, React Native really shines - over 600K projects in production, a stable router, support for 120fps animations, and regular feature updates make Expo the natural choice for developing React Native apps.

The Winner: Native (React Native + Expo)

UNA + React PWA + React Native Apps

The core UNA framework is a full-stack solution that handles the database, business logic, and HTML frontend. In addition, we offer a simple React Native wrapper app that embeds the main UNA UI in a webview. UNA also provides API endpoints that can be used to create alternative UIs, integrate 3rd-party services, and incorporate UNA functionality into other apps.

However, until recently, UNA did not provide a Single-Page-App UI or a fully native app.

Earlier this year, we took on our biggest development challenge yet. Knowing what our customers ultimately need, and regardless of the complexity and effort required, we decided to build a "no compromise" frontend app for UNA: a Universal App that shares one codebase and compiles to a NextJS web app, as well as to iOS and Android native apps. We named it NEO.

There is so much we want to share about NEO and the new chapter for UNA. It will take several posts to cover the technology, structure, and ideas for using NEO for your network. So stay tuned and buckle up. The next post will come with a demo!

💓 2
  • 6114
  • More
Comments (13)
    • General availability date for NEO is not set yet, however we already implement it for tailored projects. If you are interested in getting fully native mobile apps and a React-based progressive web app for your UNA network - get in touch and let's talk.

      • Hi @Andrey Yasko. Thanks for sharing the UNA progress in Native apps. Nice work! With the introduction of NEO, will you drop NEXUS? So what is the future of the current UNA mobile apps? Will they be discontinued? Thanks

        • Nice!

          • Добрый день. Извиняюсь, что не на английском пишу в международном сообществе, но я видел что разработчики отвечают на родном языке.

            Правильно ли я понял, что весь проект una переезжает на новый стэк технологий nextjs с соответствующим технологическим окружением и вы избавляетесь от php? Или речь идет только о мобильных приложениях и react native? Было бы невероятно круто иметь проект una на ts+nextjs+tailwind+postgresql. Это очень сильно бы развязало руки для написания кастомных модулей и прочего.

            Спасибо <3

            P.S. Я не так давно знаком с проектом una и удивлен почему о нем так мало информации в среде FOSS сообщества. Да, понятно что это коммерческий проект, но коммерческий он только в том плане, если вы хотите на базе него создать свой коммерческий проект. Все остальное под свободной лицензией. Познакомился я с una и был им покорен, по всем пунктам, кроме одного - php. Поэтому главная надежда на переезд в сторону стэка nextjs.

            • Great question @nims !

              UNA is not switching to the new stack. Instead we are creating a new frontend layer using the new stack. We choose to keep PHP for server side logic and MySQL for database. It may not be the most trendy and new combo, but modern PHP can be adapted to be very performant and it benefits from large pool of devs that can maintain it. Same goes for MySQL- it’s reliable, secure and scalable. Whenever there’s an issue chances are that there’s an extension or a tool that addresses it and it has been used in large scale production.

              Now, frontend is different. There’s only so much you can do with HTML until some sort of JS framework is required. We decided to go with React for web and ReactNative for native. For web we use NextJS meta framework and for native we use Expo to streamline the development.

              There is a lot more to it, of course. UNA is a complex platform so some components definitely call for other underlying solutions. For example, at scale certain calculations or queries may become cumbersome. This doesn’t mean that entire system needs to be rebuilt with another stack, which would ultimately underperform on some specific tasks anyway. Instead we need to embrace microservices architecture and isolate high load tasks to specialised workers, written and configured in a way that suits the challenge. For example, your feed calculation and associated queries may take 5 milliseconds with PHP and MySQL but at scale with large tables it may creep to, say, 5 seconds! If we do it in runtime the site becomes unusable. We could rewrite the whole app in something like Rust and use Postgres, but not only it would take 10 years - it would also make it much harder to find people to maintain it, documentation to understand it and tools to extend it. Solution? Instead we can isolate the particular issue and do things like adding multithreading to PHP, denormalising and cashing feed calculations, storing their cache in redis, etc etc. We can ultimately even create a separate Rust/Golang script that handles calculations and stores them in the most performant type of database. Point is that until certain workloads become large it’s best have everything handled by the most reliable and complete framework - PHP/MySQL is great for that.

              With the new frontend we get data from the PHP server via json api and websockets. We still render most screens on server (with NextJS) and stream some of the data in asynchronously using dynamic imports. It’s a mix of rendering and routing strategies - different for web and native, different for spaciest types pages - feeds, browsing, static, lists, changing/unchanging etc. React unlocks a lot of new strategies and that’s what NEO is for.

              • Отличный вопрос, @nims!

                UNA не переключается на новый стек. Мы создаем новый интерфейс с использованием нового стека. Мы решили оставить PHP для серверной логики и MySQL для базы данных. Не самое модное решение, но современный PHP можно адаптировать для высокой производительности и он пользуется большим количеством разработчиков, которые могут его поддерживать. То же самое касается MySQL - он надежен, безопасен и масштабируем. В случае возникновения проблемы всегда есть расширение или компонент который ее решает и проверен в крупномасштабном формате.

                Мы решили использовать React для веба и ReactNative для нативных приложений. Для веба мы используем метафреймворк NextJS, а для нативных приложений - Expo для упрощения разработки.

                UNA - сложная платформа, поэтому некоторые компоненты определенно требуют других базовых решений. Например, в масштабе определенные вычисления или запросы могут стать медленными. Это не означает, что весь системный стек нужно перестраивать с использованием других технологий. Вместо этого нам нужно использовать архитектуру микросервисов и выделить задачи с высокой нагрузкой на специализированные обработчики, написанные и настроенные таким образом, чтобы они соответствовали вызову. Например, расчет ленты и связанные с ней запросы могут занять 5 миллисекунд с PHP и MySQL, но в масштабе с большими таблицами это может увеличиться до, скажем, 5 секунд! Если мы делаем это в реальном времени, сайт становится непригодным для использования. Мы могли бы переписать всё приложение на Rust и использовать Postgres, но это заняло бы 10 лет, и было бы гораздо сложнее найти людей, которые могут его поддерживать, документацию для понимания и инструменты для его расширения. Решение? Вместо этого мы можем выделить конкретную проблему и сделать такие вещи, как добавление многопоточности в PHP, денормализация и кэширование расчетов ленты, хранение их кеша в Redis и т.д. В конечном итоге, мы даже можем создать отдельный скрипт на Rust/Golang, который обрабатывает расчеты и хранит их в наиболее производительном типе базы данных. Главное, что до тех пор, пока нагрузка не станет большой, лучше всего использовать наиболее надежный и полный фреймворк - PHP/MySQL.

                С новым интерфейсом мы получаем данные с сервера PHP через json api и веб-сокеты. Мы отрисовываем большинство страниц на сервере (с использованием NextJS) и асинхронно передаем часть данных с помощью динамических импортов. Это смесь стратегий отрисовки и маршрутизации - разная для веба и нативных приложений, разная для разных типов страниц - ленты, просмотра, статических, списков, изменяющихся/неизменяющихся и т.д. React открывает множество новых стратегий, для чего и нужен NEO.

                • Большое спасибо за такой развернутый ответ. Спасибо, что оставляете проект свободным и не привязываете его к конкретным сервисам для деплоя, типа DigitalOcean, Google Cloud или Amazon, как это делает тот же Forem. Возможность деплоя на любую чистую VPS - это прекрасно. Успехов Вам и чтобы о вас заговорили так же громко, как это недавно было с Mastodon.

                • Exciting work. However, as stated previously, if UNA team does not put together a robust and affordable support system to the platform, I see it eventually dying away, with bugs and glitches in members sites erupts regularly with not enough attention to address them from UNA team. A simple sad reality reflected by by browsing this forum and personal experience.

                  • We are rearranging out support and deployment system now. Basically every account here will have a "Project" set up for each domain/site launched and registered with UNA keys&secrets. Each project has its own Tasks for support requests and tracking to get direct support from UNA team. This sill be tied to subscription levels, and tailored support options, naturally, however the core-dev/setup/billing issues would be addressed for free.

                    • Thanks for the update @Andrey Yasko . Just to clarify, when you see "every account here" do you mean the new (UNA+NEO=PAW) or you mean the current subscription we have right now?

                      • Every account that registers a domain with key&secret, regardless of subscription. The subscription only defines if Pro Apps are available for auto-download and also level of service (direct support).

                      • You do amazing work here. I've known of your project for a number of years, long before UNA existed. Had a site many years ago running an early version of Dolphin. I've not found another project that comes close to UNA, let alone one with an MIT license. Thank you and your team for all you do!

                        • I made a PWA app using Chrome on Android, and a PC app using Edge on Windows. It works as you want with UNA and with things like CPanel. Phone apps might become obsolete in the future, since you can make an app out of any site, using PWA.

                          Login or Join to comment.