Entwicklung & Code
Programmiersprache Python: Performante Algorithmen entwickeln und optimieren
Plant man eine Reise durch mehrere Städte und will die kürzeste Route finden, greift man auf Algorithmen zurück, eine wohldefinierte Abfolge deterministischer Operationen. Dieser Artikel begleitet den Entwicklungsprozess eines Algorithmus, der kürzeste Wege zwischen Städten findet. Er zeigt Schritt für Schritt den Weg von der ersten Skizze über Tests und Visualisierung mit Matplotlib und NetworkX bis zur Optimierung durch geeignete Datenstrukturen. So entsteht ein Programm, das nicht nur funktional korrekt arbeitet, sondern auch performant ist.
Weiterlesen nach der Anzeige

Michael Inden ist Java- und Python-Enthusiast mit über zwanzig Jahren Berufserfahrung. Derzeit ist er als Head of Development tätig, spricht auf Konferenzen und schreibt Fachbücher über Java und Python.
Ziel ist, in einem Straßennetz diejenigen Wege zu finden, die Städte am kürzesten verbinden. Zur Modellierung kann man Graphen verwenden. In Abbildung 1 repräsentieren Kreise mit Beschriftung die Städte und die Verbindungslinien mit Zahlen entsprechen Wegen mit Distanzen.

Ein Graph visualisiert die Abstände von Städten; die Zahlen stehen für die Entfernungen (Abb. 1).
Für diese vereinfachte Karte soll der kürzeste Weg von A nach D gefunden werden. Während man bei wenigen Städten und Verbindungen alle Möglichkeiten ausprobieren kann, wird der Ansatz aufwendiger, je mehr Städte und Verbindungen existieren. Folgende Verbindungen sind möglich, wobei 13 die schlechteste ist und 6 die beste:
A -> B -> C -> D => 5 + 1 + 7 = 13
A -> C -> B -> D => 2 + 1 + 3 = 6
A -> C -> D => 2 + 7 = 9
A -> B -> D => 5 + 3 = 8
Mit der O-Notation die Effizienz verstehen
Für eine gute Bedienbarkeit von Programmen ist relevant, wie schnell sich Berechnungen und Operationen ausführen lassen. Das gilt vor allem bei großen Datenmengen. Die O-Notation erlaubt es, Algorithmen zu klassifizieren und das Wachstum der Laufzeit (oder des Speicherbedarfs) eines Algorithmus zu beschreiben, wenn die Eingabemenge größer wird. Somit sind Effekte vorhersagbar, etwa wenn eine Liste nicht mehr 10 oder 20, sondern 100.000 und mehr Daten enthält.
Weiterlesen nach der Anzeige
Die O-Notation hilft, die Laufzeit von Operationen einzuschätzen. Sie ordnet Algorithmen und Funktionen in Komplexitätsklassen ein. Bei O(n³) wächst die Anzahl der Schritte mit der dritten Potenz der Eingabemenge. Bei 100 Eingabedaten ergibt sich ein Aufwand von 1003 für die Berechnung, also 1.000.000 Schritte. Je niedriger die Komplexitätsklasse ist, desto besser. Weitere Klassen zeigt die Tabelle „O-Notation mit in Komplexitätsklassen eingeteilten Algorithmen“, Abbildung 2 visualisiert die Effekte.
| O-Notation mit in Komplexitätsklassen eingeteilten Algorithmen | ||
| Notation | Bedeutung, Wachstum | Beispiel |
| O(1) | konstant | Zugriff auf ein Listenelement |
| O(log n) | logarithmisch | Binärsuche |
| O(n) | linear | einfache Schleife über alle Elemente |
| O(n log n) | linear-logarithmisch | effiziente Sortieralgorithmen (etwa Mergesort) |
| O(n²) | quadratisch | zweifach verschachtelte Schleife |
| O(n3) | kubisch | dreifach verschachtelte Schleife |

Die Graphen zeigen die Anzahl der Operationen in Abhängigkeit von der Eingabegröße (Abb. 2).
Eine Klassifikation mit der O-Notation ist insbesondere wichtig, um Laufzeiten unabhängig von Hardwareausstattung, Implementierungsdetails und gewählten Programmiersprachen bezüglich ihrer Skalierungseigenschaften zu vergleichen.
Für eine vereinfachte Einschätzung betrachtet man bei der Bewertung nur den dominierenden Term, da bei großen Eingabegrößen kleine Konstanten oder niedrigere Terme und Faktoren vernachlässigbar sind. In der Formel n3 + 4n² + 3n + 7 folgt durch die Vereinfachungen die Laufzeitklasse O(n3).
Von der Idee zum Programm
Ein systematisches Vorgehen ist selbst für kleinere Programme und vor allem bei komplexen Softwareprojekten der Schlüssel zu funktionalem, wartbarem und performantem Code.
1. Problem verstehen und analysieren
- klären, welches Problem zu lösen ist, und es in Teilaufgaben zerlegen;
- prüfen, ob es bereits bewährte Lösungen für Teilaufgaben gibt, beispielsweise Binärsuche für performante Suchen in sortierten Datenbeständen, Dijkstra-Algorithmus für kürzeste Wege;
- Eingabe- und Ausgabedaten definieren;
- Randbedingungen und Sonderfälle berücksichtigen.
2. Planen und eine Grobstruktur entwickeln
- Problem in Teilaufgaben zerlegen;
- Abläufe in natürlicher Sprache formulieren oder skizzieren;
- geeignete Datenstrukturen wählen (Listen, Dictionaries, Heaps).
3. Implementierung
- Sourcecode in klar getrennte Funktionen oder Klassen gliedern;
- auf Lesbarkeit und Verständlichkeit achten, aussagekräftige Namen und (falls sinnvoll) ergänzende Kommentare verwenden;
- vorhandene Bibliotheken nutzen, um Entwicklungszeit zu sparen (etwa Matplotlib zur Visualisierung).
4. Testen (Dry-Run- und Unit-Tests)
- Funktionsweise ausprobieren;
- Unit-Tests schreiben, um die Funktionsweise zu prüfen und Rand- und Sonderfälle abzudecken.
5. Performance messen
- Messungen mit kleinen, mittleren und großen Datenbeständen ausführen, etwa mit 100, 10.000 und 1.000.000 Datensätzen;
- Engpässe identifizieren – sie zeigen sich allerdings meist erst bei sehr großen Datenbeständen.
6. Optimieren
Wurden in Schritt 5 Schwachstellen aufgedeckt, sollte man die Umsetzung und die gewählten Algorithmen für Teilprobleme nochmals genauer anschauen.
- O-Notation verwenden, um die Komplexität formal zu bewerten: Was läuft in Schleifen? Wie und wo erfolgt eine Suche – linear oder mit Binärsuche? Für verschiedene Aktionen kann das Laufzeiten von O(1)
, O(log n) oder O(n)bedeuten. - besser geeignete Algorithmen oder effizientere Datenstrukturen einsetzen.
Implementierung und Test miteinander verweben
In der Praxis laufen die Schritte 3 und 4 nicht immer unabhängig voneinander. Wenn sich die Ergebnisse gut vorhersagen lassen, bietet es sich an, mit dem Erstellen von Testfällen zu starten. Manchmal braucht es aber erst einmal eine Idee und einen Prototyp der Implementierung. Gerade bei größeren Programmierprojekten ergeben sich weitere Anforderungen während der Implementierungs- und Testphase.
Der folgende Ablauf hat sich in der Praxis bewährt und lässt sich auch beim Entwickeln eines Algorithmus anwenden.
Entwicklung & Code
Model-Schau: Coding, OCR und chinesisches Neujahr
Seit der letzten Model-Schau Ende Januar hat sich einiges bei den Sprachmodellen getan. Eine große Rolle scheint dabei das chinesische Neujahr zu spielen, vor dem die Anbieter nochmal viele Modelle veröffentlicht haben. Doch der Reihe nach!
Weiterlesen nach der Anzeige

Prof. Dr. Christian Winkler beschäftigt sich speziell mit der automatisierten Analyse natürlichsprachiger Texte (NLP). Als Professor an der TH Nürnberg konzentriert er sich bei seiner Forschung auf die Optimierung der User Experience.
Coding-Modelle
Schon im September 2025 hat Qwen Modelle mit einer neuen, hybriden Architektur angekündigt. Das einzige verfügbare Modell war Qwen3-Next-80B-A3B-Instruct, das aber mehr als Experiment zu betrachten war. Allerdings hat Qwen die vorgestellte Architektur in das Modell Qwen3 Coder-Next übernommen. Auch die Anzahl der (aktiven) Parameter stimmt genau überein. Hervorzuheben sind die hybriden Attention-Layer, die einen sehr langen Kontext von 262.144 Token erlauben, dabei nicht sehr viel Speicher benötigen und damit auch die Rechengeschwindigkeit kaum reduzieren.
Dadurch ist Qwen3-Coder-Next auf eigener Hardware schnell ablauffähig, wenn ausreichend Speicher zur Verfügung steht, was vor allem bei leistungsfähigen Macs mit Apple Silicon der Fall sein dürfte. So hat sich das Modell bei einigen Developern zu einem Lieblingsmodell für den lokalen Betrieb gemausert. Einige sind davon sogar so begeistert, dass sie es auch abseits vom Coding einsetzen.
(Bild: Golden Sikorka/Shutterstock)

Die Online-Konferenz LLMs im Unternehmen zeigt am 19. März, wie KI-Agenten Arbeitsprozesse übernehmen können, wie LLMs beim Extrahieren der Daten helfen und wie man Modelle effizient im eigenen Rechenzentrum betreibt.
OpenAI musste nachlegen und hat das Modell GPT-5.3-Codex veröffentlicht. Laut eigener Beschreibung ist es deutlich schneller als das Vorgängermodell und besser für agentische Aufgaben geeignet. Das neue Modell kann Code Reviews durchführen und OpenAI hat es inzwischen durch das kleinere Modell GPT-5.3-Codex-Spark ergänzt. Damit soll es sich auch für Realtime-Coding eignen. Sicher spürt OpenAI allerdings auch den Preisdruck, der durch die offenen Modelle entsteht. Coding-Modelle produzieren (insbesondere wenn sie Reasoning verwenden) notorisch viele Token, was sich in sehr hohen Kosten manifestieren kann.
Auch Coding-Primus Anthropic hat mit Claude Opus 4.6 ein neues Modell geschaffen, das sich hervorragend für Coding-Aufgaben eignet. Zusätzlich kann Opus 4.6 Finanzanalysen durchführen, Präsentationen erstellen und viele Aufgaben des täglichen Lebens übernehmen. Nicht zuletzt deswegen nutzen es viele auch für OpenClaw, was aber schnell zu unabsehbaren Kosten führen kann. Sowohl im Bereich Text als auch beim Coding ist Opus 4.6 unangefochtener Sieger bei den Arena-Leaderboards.
Weiterlesen nach der Anzeige
Wie man Coding-Modelle wirklich effizient nutzt und was man damit alles erreichen kann, hat Steve Yegge mit seinem viel beachteten Gas Town erklärt und das entsprechende Tooling gleich mit implementiert. Yegge spart dabei nicht mit Warnungen, dass man das System nur dann nutzen sollte, wenn man über die notwendigen Erfahrungen verfügt und sich auf dieses neue Paradigma auch wirklich einlassen möchte. Teilweise sind die Vorschläge extrem, aber es könnte dennoch einen Ausblick darauf bieten, wie sich agentisches Coding mit LLMs in Zukunft weiterentwickeln kann. Vorsicht ist allerdings geboten, weil Gas Town Token „verbrennt“ – die Kosten können geradezu explodieren, wenn man ein teures Modell verwendet.
OCR-Modelle
Durch die Vision-Language-Modelle ist OCR mehr und mehr zu einer Domäne der großen Sprachmodelle geworden. Nachdem es einige Monate in diesem Bereich ziemlich ruhig war, erschienen nun gleich mehrere neue Modelle.
Sehr beliebt ist das neue GLM-OCR-Modell von Z.ai. Obwohl der Anbieter ein Newcomer bei OCR-Modellen ist, stellt das Modell zumindest nach den Benchmarks die ebenfalls neuen DeepSeek-OCR-2 und PaddleOCR-VL-1.5 in den Schatten. Eine in früheren Tests verwendete iX-Seite kann das Modell nicht ganz fehlerfrei in Text wandeln, kommt aber mit den Spalten bestens zurecht – das Ergebnis liegt nur als Text vor, ist aber gut verwendbar.
Tabellen und Formeln kann GLM-OCR auch interpretieren, die Wandlung von Grafiken in Daten ist aber bisher nicht möglich.
Aber auch DeepSeek-OCR-2 hat sich gegenüber seinem Vorgänger deutlich weiterentwickelt und nutzt nun ein – interessanterweise altes – Qwen-VL-Modell als Encoder. Die iX-Seite wird dabei perfekt erkannt:

DeepSeek-OCR2 erkennt die iX-Seite sehr gut (Abb. 1).
Auch das konvertierte Markdown sieht gut aus.
PaddleOCR-VL-1.5 nutzt einige neue Ansätze wie Text Spotting und kann auch Textboxen erkennen, die nicht rechteckig sind. Ein Fokus liegt außerdem auf Tabellen, die es auch über mehrere Seiten zusammensetzen kann. Als einziges der genannten Systeme kann PaddleOCR-VL-1.5 Daten aus Diagrammen extrahieren. Die iX-Seite verarbeitet es gut und benötigt dabei zwar wenig Speicher, rechnet aber äußerst lange.
Es wäre spannend zu erfahren, ob die Anbieter die aus PDF extrahierten Texte auch als Trainingsdaten für ihre großen Sprachmodelle nutzen. Dazu schweigen sich jedoch alle aus.
Neue Modelle aus China
Die stets aktiven Anbieter aus China haben sich in den vergangenen Wochen selbst übertroffen. Angeblich soll das am chinesischen Neujahr liegen, das traditionell mit Urlaub verbunden ist.
Kimi K2.5 wird von vielen als das aktuell stärkste Modell mit offenen Gewichten wahrgenommen. Moonshot hat das Modell zwar schon vor einer Weile veröffentlicht, die technischen Informationen waren aber nur spärlich. Das hat sich nun geändert, weil der zugehörige technische Bericht jetzt bereitsteht. Das Dokument berichtet ausführlich über das Training und die Evaluation des Modells. Besonders das Training hat es dabei in sich, denn Moonshot hat sowohl im Pre-Training als auch beim Reinforcement Learning multimodale Daten verwendet. Das erklärt möglicherweise auch, warum Kimi K2.5 so weit oben in der Vision-Rangliste bei arena.ai steht. Eine weitere Besonderheit stellt Agent Swarm dar: Das Modell kann Agentenaufrufe parallel durchführen, was die Geschwindigkeit bei komplexen Aufgaben stark erhöht. Diese Anforderungen berücksichtigt Moonshot bereits beim Training. Die Autoren beschreiben auch Details des Trainingsprozesses, verschweigen aber die benötigte Rechenzeit. Im Vergleich zu DeepSeek geht der Bericht weniger in die Tiefe, aber viele Details sind dennoch sehr interessant.
Mit Step-3.5-Flash betritt ein weiterer, bisher weitgehend unbekannter Player die Bühne der großen (chinesischen) Sprachmodelle. Im Vergleich zu Kimi K2.5 ist das Modell regelrecht klein, auch wenn es über 196 Milliarden Parameter verfügt (von denen elf Milliarden aktiv sind). Diese Größe ermöglicht es aber, das Modell auch auf leistungsfähiger (Mac-) Hardware in einer quantisierten Version zu betreiben. Für ein derart kleines Modell produziert es sehr ansehnliche Ergebnisse, ist aber in ersten Tests auch sehr stark chinesisch indoktriniert. Bei der Frage nach dem Heise Verlag liegt es mit dem Gründungsjahr und dem Gründer falsch. Bei politisch sensiblen Fragen verweigert sich das Modell.
Das trifft in diesem Maße nicht auf GLM 5.0 zu. Z.ai ist ein in der Zwischenzeit etablierter Anbieter offener Sprachmodelle, der auch sehr bereitwillig Auskunft über politisch heikle Themen gibt. Die Community hat diesem Modell entgegengefiebert und wurde nicht enttäuscht. Gar nicht lange nach GLM 4.7 liefert Z.ai ein extrem starkes Modell, das es insbesondere beim Coding mit fast allen kommerziellen Modellen aufnehmen kann. Auch sonst hat GLM 5.0 eine starke Performance, aber im Vergleich zum Vorgänger die Anzahl der Parameter auf 744 Milliarden Parameter (davon 40 Milliarden aktiv) mehr als verdoppelt. Es benötigte bei einer geeigneten Quantisierung auf einem Mac Studio stolze 512 GByte RAM, wenn man sich nicht in noch höhere Kosten für GPUs stürzen möchte. In den Arena-Benchmarks schneidet das Modell hervorragend ab. In unseren Tests konnte es (als eines der wenigen Modelle) das Gründungsjahr und den Gründer des Heise Verlags korrekt nennen.
Da konnte MiniMax nicht zurückstehen und hat auch noch ein neues Modell veröffentlicht. MiniMax 2.5 ist mit 230 Milliarden Parametern (davon zehn Milliarden aktiv) deutlich kleiner und kann in einer geeigneten Quantisierung auch mit 128 GByte RAM auf der CPU laufen. Noch ist es nicht in vielen Benchmarks vertreten, aber die ersten Resultate sehen gut aus. In ersten Tests gibt auch MiniMax 2.5 falsche Antworten zum Heise Verlag. Bei Fragen zu politisch heiklen Themen in China bleibt es neutral, aber sehr kurz angebunden.
Weniger stark beachtet, aber dennoch interessant ist das Modell Nanbeige4.1-3B. Es handelt sich um ein „kleines“ Reasoning-Modell mit lediglich drei Milliarden Parametern, das aber in bestimmten Benchmarks die viel größeren Qwen3-Modelle mit bis zu 32 Milliarden Parametern schlägt. Als erstes kleines Sprachmodell beherrscht es auch Deep Search und kann in bis zu 500 Runden Tools aufrufen. Es wird spannend, ob andere Modelle nachziehen können, beziehungsweise welche Fähigkeiten die großen Modelle erlangen, wenn sie ähnliche Mechanismen einsetzen.
Lange erwartet und vor ganz kurzem erschienen ist nun auch Qwen3.5. Das Modell steht in unterschiedlichen Größen zur Verfügung, allerdings fehlen aktuell noch die kleineren Modelle. Schon jetzt zeigt sich allerdings, dass Qwen3.5 sehr leistungsfähig ist und gegenüber der vorherigen Version sehr viel Boden gutgemacht hat. Die großen Qwen3.5-Modelle (wie 122B) spielen dabei fast schon in der gleichen Liga wie (das viel größere) Stepfun. Eine genauere Analyse folgt im nächsten Artikel.
Open Responses
Als Interoperabilitätsstandard hat sich die OpenAI-API etabliert. Fast immer wird dabei die completions-Ressource angefragt, obwohl der Name eigentlich nicht mehr zeitgemäß ist. Auch die Übergabe weiterer Parameter ist eher historisch gewachsen als inhaltlich motiviert. Verschlüsselung beherrscht das Interface in dieser Form gar nicht.
All diesen Problemen hat sich ursprünglich OpenAI angenommen und dafür die Responses-API geschaffen, deren Weiterentwicklung unter dem Namen Open Responses die Community übernommen hat. Auch den Umgang mit Agenten beherrscht das neue Format besser und kann somit Reasoning-Zyklen umgehen. Dabei legt das Protokoll unter anderem fest, wie viele Tools maximal aufgerufen werden dürfen.
Viele Werkzeuge unterstützen die neue API bereits. Eine Standardisierung ist nicht nur sinnvoll, sondern wichtig, weil durch die agentische Interaktion eine immer bessere Konfigurierbarkeit der Schnittstellen dringend notwendig wird.
Rasante Neuerungen, aber mit Grenzen
Die Geschwindigkeit, mit der die Anbieter neue Modelle vorstellen, hat sich in den letzten Monaten eher noch einmal erhöht. Ob das so weitergehen kann, sei dahingestellt. OpenAI stellt jedenfalls schon weniger neues Personal ein. Bei den chinesischen Anbietern ist es wesentlich intransparenter, wie lange sie sich das leisten können. Insbesondere fehlt es dort auch an Umsatz, der sich mit den offenen Modellen deutlich schwerer (und vor allem extrem schwer außerhalb Chinas) erzielen lässt.
Hinzu kommt der Hype um OpenClaw als Agent. Dessen Betrieb ist mit offenen Modellen sogar autark möglich, allerdings sind auch dann die Sicherheitsprobleme erheblich. Wenn man die Berichte darüber liest, fragt man sich, ob die Technologie wirklich schon reif genug ist, sie so „von der Leine“ zu lassen. Die Diskussionen über die Guardrails bekommen so eine ganze neue Dimension. Das trifft nicht für alle Anwender zu: Das amerikanische Verteidigungsministerium wollte Anthropic dazu zwingen, genau diese Guardrails in den von ihnen genutzten Modellen abzuschalten. Anthropic blieb standhaft. Zwar sind sie nun ihren Auftrag los, haben aber ChatGPT in den Popularitätswerten überholt.
(rme)
Entwicklung & Code
Gram: Komplett KI-freier Coding-Editor | heise online
Ganz gegen den Trend gibt es jetzt einen Coding-Editor, der komplett auf KI-Funktionen verzichtet: Gram 1. Er basiert auf dem Editor Zed und verzichtet auf KI, automatische Updates, Telemetrie, Abos und Collaboration.
Weiterlesen nach der Anzeige
Als Begründung für die Abspaltung von Zed nennt der Blog insbesondere die schnelle Weiterentwicklung von Zed, die dem Autor immer mehr irrelevante Patches lieferte. „Ab jetzt habe ich entschieden, damit aufzuhören.“ Die Ablehnung von KI begründet der Verfasser des Beitrags – vermutlich der Hauptkontributor des Projekts Kristoffer Grönlund – damit, dass er als Lehrer festgestellt hat, dass Schülerinnen und Schüler keine Programmiersprache mehr lernen können, weil sofort der Coding-Assistent anspringt: „Sie kommen gerade so weit, ‚pr-’ einzutippen, und sofort beginnt der Editor, die Schüler mit unsinnigen Vorschlägen, Aufforderungen und Ablenkungen zu bombardieren.“
Zed-Extensions lassen sich nutzen
Da Gram auf Zed basiert, funktionieren dessen Extensions nach wie vor, Anwender müssen sie aber aus den Quellen bauen und selbst updaten. Automatische Aktualisierungen sind deaktiviert. Auch Sprachserver und Node.js müssen manuell zugefügt werden. Dafür ist die Dokumentation im Editor integriert, und er unterstützt weitere Sprachen wie Gleam, Zig und Odin.
Binaries für den in Rust geschriebenen Editor gibt es für Mac sowie Linux, und weitere Informationen finden sich im Blog und auf Codeberg. Hier heißt es ganz klar: „Agenten sind von diesem Projekt ausgeschlossen.“ Auch Zed selbst bietet im Übrigen eine Möglichkeit, KI-Funktionen auszuschalten.
Weiterlesen nach der Anzeige
(who)
Entwicklung & Code
GitHub-Store 1.6.0: Plattformübergreifender App-Store für Open-Source
Der plattformübergreifende App-Store GitHub-Store ist in Version 1.6.0 erschienen. Die neue Version erweitert die Unterstützung für Linux-Systeme und bringt zahlreiche Funktionsverbesserungen für die Verwaltung von Open-Source-Anwendungen. Das Projekt ist trotz des Namens kein offizielles Microsoft-Produkt.
Weiterlesen nach der Anzeige
Ein Store für GitHub-Projekte
GitHub-Store ist ein freier App-Store, der sich auf Open-Source-Anwendungen konzentriert. Anders als etablierte Stores wie der Google Play Store oder F-Droid nutzt die Anwendung die GitHub Search API und die Releases API, um automatisch Projekte zu finden, die installierbare Binaries bereitstellen. Entwickler müssen ihre Apps nicht manuell einreichen – der Store zeigt automatisch alle GitHub-Repositories an, die in ihren Releases passende Installationsdateien wie APK, EXE oder DMG anbieten.
Das Projekt basiert auf Kotlin Multiplatform und Compose Multiplatform, was eine einheitliche Codebasis für verschiedene Betriebssysteme ermöglicht. Die Anwendung läuft auf Android, Windows, macOS und Linux, wobei sie automatisch die passenden Assets für die jeweilige Plattform erkennt und zum Download anbietet. Installierte Apps lassen sich über den Store auf Updates überwachen.
Neue Features in Version 1.6.0
Nutzer können ab sofort direkt im Store ihre mit GitHub-Sternen markierten Repositories anzeigen lassen, was die Verwaltung favorisierter Projekte vereinfacht. Für Linux-Anwender stehen sowohl AppImage-Dateien als auch Debian-Packages für Debian 12 zur Verfügung.
Entwicklerprofile ermöglichen es, mehr über die Urheber von Projekten zu erfahren. Deep Linking erlaubt das direkte Öffnen bestimmter Apps oder Bereiche im Store über URLs. Die Verwaltung von Releases und installierten Anwendungen wurde ebenfalls überarbeitet.
Weiterlesen nach der Anzeige
Für Nutzer in Regionen mit Netzwerkbeschränkungen bietet Version 1.6.0 eine dynamische Proxy-Unterstützung. Ein verbessertes Caching-System beschleunigt das Laden von Inhalten erheblich. Auch manuelle Installationen von APK-Dateien sind nun möglich, begleitet von nativen Splash-Screens beim App-Start.
Die Benutzeroberfläche haben die Entwickler ebenfalls aktualisiert: Neue „Liquid Glass Chips“ genannte UI-Elemente, überarbeitete Icons und integrierte Übersetzungen sollen die Bedienung verbessern. Die Community trug Übersetzungen in Polnisch, Türkisch, Bengalisch und Hindi bei.
Unter der Haube wurde die Codebasis modularisiert, was zukünftige Erweiterungen und Wartungsarbeiten vereinfachen soll. Die Suchfunktion wurde komplett überarbeitet, diverse Fehler behoben – darunter Probleme bei der Erkennung der APK-Architektur. Auch die Dokumentation und die Security Policy wurden aktualisiert. Detaillierte Informationen zu allen Änderungen finden sich in den offiziellen Release Notes.
Kontroverse um Googles Android-Richtlinien
Die Veröffentlichung erfolgt vor dem Hintergrund einer Kontroverse um Googles geplante Änderungen an Android. In den Release Notes warnt das Projekt: „Freies und Open-Source-Android ist bedroht“. Google plant ab Herbst 2026, auf zertifizierten Android-Geräten eine Registrierungspflicht auch für App-Entwickler einzuführen, die ihre Software außerhalb des Play Store verbreiten wollen.
Gegen diese Pläne richtet sich ein aktueller offener Brief, den Organisationen wie der Chaos Computer Club, die Free Software Foundation, Tuta, Vivaldi und Codeberg unterzeichnet haben. Die Kritik richtet sich gegen die Torwächterrolle Googles, anfallende Gebühren, Ausweispflichten und mögliche Datenschutzrisiken. Auch wenn kein vollständiges Sideloading-Verbot geplant ist, befürchten Kritiker eine Wettbewerbsverzerrung und erhebliche Hürden für unabhängige Entwickler.
GitHub-Store positioniert sich auch vor diesem Hintergrund explizit als Alternative für Nutzer, die ihre Freiheit bei der Software-Installation bewahren möchten. Das Projekt verweist ferner auf die Initiative keepandroidopen.org, die sich für ein offenes Android-Ökosystem einsetzt.
(fo)
-
Künstliche Intelligenzvor 2 MonatenSchnelles Boot statt Bus und Bahn: Was sich von London und New York lernen lässt
-
Social Mediavor 3 WochenCommunity Management zwischen Reichweite und Verantwortung
-
Künstliche Intelligenzvor 2 Wochen
Top 10: Die beste kabellose Überwachungskamera im Test – Akku, WLAN, LTE & Solar
-
Social Mediavor 1 TagCommunity Management und Zielgruppen-Analyse: Die besten Insights aus Blog und Podcast
-
Datenschutz & Sicherheitvor 3 MonatenSyncthing‑Fork unter fremder Kontrolle? Community schluckt das nicht
-
Entwicklung & Codevor 3 MonatenKommentar: Anthropic verschenkt MCP – mit fragwürdigen Hintertüren
-
Künstliche Intelligenzvor 3 MonatenGame Over: JetBrains beendet Fleet und startet mit KI‑Plattform neu
-
Social Mediavor 3 MonatenDie meistgehörten Gastfolgen 2025 im Feed & Fudder Podcast – Social Media, Recruiting und Karriere-Insights
