Qt-utveckling i Göteborg — för industriella produkter, embedded och desktop

Intunio är en design- och utvecklingsstudio i Göteborg. Qt är ramverket vi väljer när mjukvaran ska köras nära hårdvaran: operatörspaneler, produktnära skärmar, kontrollgränssnitt och desktop-applikationer som ska fungera likadant på Windows, Linux och macOS. Vi bygger gränssnitten i QML och logiken i C++.

Qt-utveckling hos oss följer samma princip som all vår apputveckling: designer och utvecklare delar backlog från dag ett. Det spelar extra stor roll i Qt-projekt, där gränssnittet ofta sitter på en fysisk produkt och varje designbeslut också är ett beslut om prestanda, hårdvara och certifieringskrav.

Det här har vi gjort med Qt

Vi har byggt Qt-baserad mjukvara i uppdrag för bland andra BlackBerry och Axis — produkter där prestanda, säkerhet och långsiktig förvaltbarhet var krav från dag ett. Erfarenheten därifrån är samma som vi tar med in i varje Qt-uppdrag: gränssnitt som ska fungera nära hårdvaran, i produkter som lever länge.

När Qt är rätt val

Qt är sällan det första ramverk som nämns i ett app-projekt — men i vissa lägen är det det självklara valet:

• Gränssnittet sitter på en enhet. Operatörspaneler, instrumentkluster, medicinteknisk utrustning, produktnära skärmar. Qt är byggt för embedded Linux, QNX och andra plattformar nära hårdvaran, och klarar låga hårdvaruresurser utan att gränssnittet känns segt.

• Samma applikation ska köras på desktop — på alla operativsystem. En kodbas i Qt levererar till Windows, Linux och macOS, med native prestanda och utan webbläsare som mellanlager.

• Prestanda och realtid är krav, inte önskemål. Qt kombinerar deklarativ UI i QML med logik i C++ — grafiktunga vyer, realtidsdata och hårdvarunära integration i samma applikation.

• Produkten lever länge. Industriella produkter förvaltas i tio år eller mer. Qt har funnits sedan 90-talet, ägs av ett noterat bolag och används av bolag som Bosch, LG och Rockwell Automation — det är ett val man kan stå för över tid.

Qt är mindre rätt när produkten är en renodlad mobilapp — Qt kan leverera till iOS och Android, men där är native eller Flutter oftast ett bättre val. Och när gränssnittet är en webbprodukt tittar vi på webb i stället. Vi väljer verktyg efter produkten, inte tvärtom.

Vad vi gör

• QML- och Qt Quick-utveckling: deklarativa, grafiktunga gränssnitt med full kontroll över uttrycket — från designsystem till pixel

• C++-integration: applikationslogik, integration mot befintliga C++-backends, drivrutiner och protokoll

• Industriella gränssnitt och HMI: operatörspaneler, kontrollgränssnitt och övervakningsvyer — i tight samspel med vår tjänst för industriell UX

• Cross-platform desktop: en kodbas för Windows, Linux och macOS

• Embedded targets: Qt på embedded Linux och andra plattformar nära hårdvaran, anpassat till skärm, minne och CPU-budget

• UX och design för Qt-produkter: vi designar gränssnittet och bygger det — samma team, samma backlog

Design och teknik hör ihop — särskilt i Qt

Qt-projekt havererar sällan på tekniken. De havererar i glappet mellan design och verklighet: gränssnittet designas framför en skärm på ett kontor, men används med handskar, i motljus, på en fabriksyta. Därför jobbar vi inte med överlämningar: designern som ritar operatörsvyn sitter i samma team som utvecklaren som implementerar den i QML.

QML gör det samspelet konkret. Gränssnittet beskrivs deklarativt, vilket betyder att ett designsystem kan översättas nästan rakt av till komponenter i kod — samma tänk som gör att vi gillar Flutter på mobil. Designbeslut blir testbara på riktig hårdvara tidigt, inte i slutet av projektet.

Hur vi jobbar

Ett Qt-projekt följer samma upplägg som vår övriga utveckling: förstudie, design- och teknisk grund, utveckling i sprintar, release och förvaltning — med designer och utvecklare i samma team. Vi börjar ofta med en förstudie som landar scope, arkitektur och om Qt verkligen är rätt val innan en rad kod skrivs. Finns det redan en Qt-kodbas börjar vi gärna med en produktvalidering som ger en ärlig bild av nuläget.