"Yes, I’ve had this problem too!"
Within Ponte, we have also run into the issue many times where we needed the same text, image, color, etc. on web, Android, and iOS. The only difference between these platforms was the file format. Text content, although stored in multiple places, is quick and easy to upload since every platform stores it as plain text.
However, image upload is far from this simple. The first challenge is handling images in the formats supported by each platform. Earlier, PNG and JPG were the most popular formats, as all mentioned platforms supported them. Today, these formats are declining because screen sizes — and therefore resolutions — are constantly changing. In response, vector images have become widely used, as a single file is enough to display images in any resolution. But the vector world introduces another layer of complexity for developers and designers, since instead of a common standard, different ecosystems diverge. Web uses the popular SVG format, iOS uses PDF, while Android uses Vector Drawable. It is immediately apparent that the first two formats (SVG and PDF) are easily manageable vector formats, while Vector Drawable does not belong to that category. A developer may be lucky if Android Studio can convert an SVG into a usable vector image — but often it cannot perform the conversion perfectly, or even adequately. This leads to 3rd party conversion tools or, in the worst case, manual work by the developer, which can consume a significant amount of time.
Further issues may arise from changes requested by the client or changes made by the development team. In the best case, updates are made perfectly and consistently across all platforms — after a few disapproving looks or comments from developers — resulting in the expected outcome. In less ideal cases, one or more platforms receive incorrect or no updates at all, creating inconsistencies that require more developer effort to fix later.
Finally, consider the case where someone from the marketing or sales team submits a request to change a resource file to improve the appearance or user experience of the system. This request reaches the developers, who make the required adjustments and deliver a new version back to the requesting group. This iteration continues until every group is satisfied. It is important to note that this cooperation is unnecessary: the developers are not performing development work but simply replacing or adjusting resource files.
The Road to Respresso
Within Ponte, we have dealt with all the issues mentioned above multiple times. To improve the situation, we tested several approaches — here are a few of them to show what motivated the development of Respresso.
Our approaches for handling localization text were the following:
- Initially, each platform stored text content in its own native format. This, as you can imagine, is the worst possible solution: modifying these texts is tedious for developers and expensive for the client.
- We quickly recognized the shortcomings of the previous approach, so we began moving as much text content as possible to the server. At first, this was only feasible on interfaces that already required server–client communication.
With this, we removed the “sting” of the problem — language-specific text retrieval was solved without significantly increasing communication needs. But what about the other text content where there was no communication at all? For those, we kept using the old approach. - We needed a shared method that did not depend on communication overhead and could still meet all platform requirements. So we created a JSON file stored on the server, and every app or website retrieved this file at launch or load. The text was then stored locally and used throughout the application.
This solution was practical: the file was downloaded only once, and clients reacted instantly to text changes. However, communication was still required, and modifying the content still required involving a developer. - Next, we wanted a solution independent of server communication but still compatible with every platform. The JSON format performed well, so we stayed with it — stored on an accessible server. We created platform-specific scripts that download the JSON, place it into the proper directories, and regenerate each platform’s required file structure. The script also handled replacing the previous file with the updated one.
We could say this fourth solution is good enough for many cases — but several issues remain. The solution still requires a developer to perform the update, and specifically one who even knows this solution exists. It relies on updating a static file using an often inconvenient tool on a server. Versioning is not supported, making it difficult to revert to earlier states.
Manage in One Place, Use Everywhere!
Learning from earlier attempts, we began designing an accessible system — available online — that gathers all resource types used during development. At the time of writing this article, Respresso supports the following resource types:
- Localization text (including multi-language support)
- Colors
- Fonts
- Images (vector)
- Application icons
When adding localization content, we can use the import function, which reads the uploaded text file — no need to enter everything manually. Colors can also be imported from a palette, and even the colors from a simple PNG file can be added. Supported font formats are TTF and OTF. For images, the system accepts vector-based files. For mobile projects, the application icon can also be managed here, supporting both vector and raster formats (PNG, JPG), even in combination.
This structure defines a project, but access must be restricted only to relevant team members. Project access is tied to user registration and group membership.
Team
Every registered user must belong to at least one group, which they can create themselves if needed. Groups contain members and projects, but not every member can edit every project — just like in real development environments, not every developer has access to every project. If someone needs access, they can request it through our invitation system.
We introduced “Team history” to display all changes made by team members. This helps developers stay informed without manually checking each project — updates are centralized and visible to everyone.
Who Can Join the Team?
In our interpretation, anyone involved with the project can join the group: developers, designers, clients, or even translation agencies. Whenever a group member modifies something, the updated version becomes available on all platforms. Developers no longer need to open projects just to update resources; they can stay focused on development.
Project
The project is the core element of Respresso — everything is built around it. A project has a unique identifier called a Project Token. Clients use this token to obtain the converted version of each requested resource.
Projects also feature a project-level history view — unlike the team-level view, this one only shows updates relevant to the specific project. Notifications can even be sent via Slack. Within a project, tokens can be rotated if absolutely necessary — but after rotation, old tokens will no longer work. Projects can also be archived without being physically deleted, allowing future modifications.
Each user can easily extend, modify, or delete resources. Conversion is handled entirely by the system — no user action is required. Conversion is performed by a set of small background processors. Each processor has one input and one output, enabling a black-box operation. Processors execute predefined tasks — from complex transformations to something as simple as removing whitespace. They can also be chained together, where the output of one processor becomes the input of the next. This keeps processors reusable and easy to understand.
Custom Processor
In an upcoming feature, users will be able to add custom processors to the Respresso execution pipeline. This makes it possible to run unique conversion logic without waiting for us to implement it. A company may use a fully custom solution, or simply need a converter we have not yet developed — in such cases, they can build and integrate their own processor.
Version Management
Every resource type in Respresso has its own independent version number. For example, Localization may be version 1.0.0 while Colors may be 1.3.2. We envisioned versioning similar to GIT (think tags), which inspired the Finalize feature.
By default, each section is editable until it is finalized. Finalization creates a restore point that preserves the context — after finalization, no additions or removals are allowed for that version. Versions can also be copied. A copy includes all current resources and can be extended further until finalized.
Clients
We consider any platform that downloads and uses server-generated resources to be a client. Our goal is to support more and more platforms over time.
Currently, Android integrates Respresso into the build process, iOS uses a command-line script, and the web uses npm to keep resources updated. Clients do not need to download every resource — for example, if a platform does not use fonts, it can skip downloading them.
More information on integrating Respresso clients is available on our GitHub page.
I'm a Manager — Is It Worth It for Me Too?
Respresso is designed to support individual developers, small teams, mid-sized companies, and large enterprises — even when using only a single platform. It stores all resources in one place and handles conversion automatically, improving comfort and workflow efficiency. It also saves time and money, as every resource (color, image, localization text, etc.) only needs to be added once — all platforms can reuse it. Based on estimates with partner companies, Respresso can reduce development time by roughly 20%. We evaluated the following factors:
- The designer can add all necessary images, fonts, colors, etc. during the project planning phase,
- Client change requests for resource files can be handled flexibly,
- It guarantees easier scalability,
- Resources such as text, images, colors, and fonts can be updated without “blocking” developers, and CI can publish a new version automatically,
- It simplifies processes by ensuring changes are always propagated.
What’s Next?
We have plenty of ideas for Respresso, but feedback from our users is even more valuable. For this reason, we created a Polly survey where anyone can submit suggestions or vote on existing ideas. We publish the results on our site at app.respresso.io.