Golang has been on the rise ever since it's release and managed to make a name for itself in the cloud development space. Popular software like Docker, Kubernetes and Caddy have all been written in Golang, bringing joy to developers at home or carrying big corporate clusters that serve our everyday needs.

Introducing Go-Mojito, a simple framework that will help you create websites and APIs with ease. Go-Mojito is the official successor to the PHP-based framework "Scalar" and is almost fully compatible with existing Website templates.

Features

While this is not a complete list of all features, it should give you an idea of what Go-Mojito is capable of (And possibly what it's not capable of).

Dependency Injection

One of the most annoying things to do is managing all your database connections, caches, logging instances, configurations... You get the idea. Go-Mojito can manage singleton as well as transient dependencies for you, and inject them where-ever you need them. This includes all handlers that are called by Go-Mojito.

package main

// Dependencies can be either inline like this
func InlineDependency(ctx mojito.Context, cache mojito.Cache) {
	...
}

// Or they can be collected in a struct
type Dependencies struct {
	Cache  mojito.Cache  `injector:"type"`
	Logger mojito.Logger `injector:"type"`
}

func StructDependency(ctx mojito.Context, ctx Dependencies) {
	...
}

In this example, you can see that dependencies can be either directly in the method signature or separated out into a struct.

Keen eyes will spot the injector:"type" tag in the struct, this tag tells the dependency injector to fill the field based on its type. That means, that whatever is registered as default for the type will be injected. The other option would be, injector:"name" which would resolve the dependency based on its type and name. This is necessary, because there can be multiple dependencies of the same type under a different name. A good example is database connections or caches.

package main

import (
	"github.com/go-mojito/mojito"
)

func main() {
	// This is how you register a singleton
	mojito.Register(func() YourType {
		var yourType YourType
		// Construct your type
		return yourType
	}, true)
    
    // And this is how you register a transient
    mojito.Register(func() YourType {
		var yourType YourType
		// Construct your type
		return yourType
	}, false)
}

Registering a new dependency is as easy as the above. You tell Go-Mojito how to construct your dependency when it's needed by providing a constructor function, the boolean tells Mojito whether this is a singleton or a transient dependency. This will register the default dependency for the returned type. If you want to have multiple dependencies of the same type under different names, you have to register it in the following way.

package main

import (
	"github.com/go-mojito/mojito"
)

func main() {
	// This is how you register a named singleton
	mojito.RegisterNamed("name", func() YourType {
		var yourType YourType
		// Construct your type
		return yourType
	}, true)
}

And that is all there is about dependency injection. It's simple, but very powerful, and will surely lessen the pain of managing your application-wide connections and objects.

Extensibility & Modularity

The framework has been designed with extensibility and modularity in mind. This is why you can replace any part of the Mojito framework with your own. Don't like the default logger? Swap it out. Fancy a different template language? Sure, replace the built-in renderer. Or just register a second one and use two template formats at the same time, it's up to you! The only thing you cannot replace is the dependency injector, as it would need to inject itself, which would make for a great paradox but not for great code :)

package main

import (
	"github.com/go-mojito/mojito"
)

func main() {
	mojito.Register(func() mojito.Logger {
		var yourType YourLogger
		// Construct your logger
		return yourType
	}, true)
}

And just like that, the default logger has been replaced, all of Go-Mojito will automatically adjust to that change. It works best when you do this in an init method, then even the very first log messages will be printed using your logger.

In fact, that is how you replace everything in Go-Mojito, just override its default dependency. Of course, if you end up replacing everything, then I would ask why you even use Mojito, perhaps because of the handlers that work the same way even when you change the router? That's right, the only thing you cannot replace is the custom handler and middleware design. This is to ensure consistency across different routers and of course to retain the dependency injection ability.

Middleware Support

Speaking of middleware, Mojito has full support for early and late middleware, meaning before and after the handler executed. Middlewares have full access to the ViewBag and any metadata set on the request. They can also modify both objects or replace them completely if needed. They can even have dependencies injected just like handlers!

package main

import (
	"fmt"

	"github.com/go-mojito/mojito"
)

func main() {
	// Enable middleware on all routes
	mojito.WithMiddleware(RequestLogger)
    
    // Or just for a subset of routes
    mojito.WithGroup("/group", func(group router.Group) {
		group.WithMiddleware(RequestLogger)
	})
}

func RequestLogger(ctx mojito.Context, next func() error) (err error) {
	var start = time.Now()
	err = next()
	mojito.DefaultLogger().Fields(LogFields{
		"ms":   time.Since(start).Milliseconds(),
		"path": ctx.Request().GetRequest().URL.Path,
	}).Info(ctx.Request().GetRequest().Method)
	return
}

Template Rendering

Of course, there is no website without HTML code. To help you reduce duplicate code and get your content into your pages, Go-Mojito ships with a template renderer. By default, standard go templates can be used. We recommend using our Handlebars renderer though. There are a few benefits to the Handlebars renderer.

First, the partial system has been extended to dynamically load partials from your template directory. That means that you do not have to register your partials before using them, but instead you can just put in the relative file path of your partial.

Second, you can extend templates! It's like reverse partials. For example, your layout can be extended by all your subpages.

<html>
    <head>
    	<title>Layout</title>
    </head>
    <body>
    	<h1> Fancy Website Here </h1>
    	{{{subview}}}
    </body>
</html>

And then you can extend the above using template code like this.

{{#extends "Path/To/Above"}}
<h2>And this is a page of this website</h2>
{{/extends}}

As you can see, everything wrapped in the extends helper will be injected into the extended template, if the extended template contains a {{{subview}}} placeholder.

Try it yourself

Using the above and the example code in the repository, you should be able to get something up and running in no time. If not, just open up an issue and tell us what went wrong. Please also consult our documentation before opening a ticket.

GitHub - go-mojito/mojito: Code your next Go web project with (a) Mojito! Mojito is a super-modular, fast, opinion-less framework to bootstrap your next Go web project.

Code your next Go web project with (a) Mojito! Mojito is a super-modular, fast, opinion-less framework to bootstrap your next Go web project. - GitHub - go-mojito/mojito: Code your next Go web proj...

GitHubgo-mojito

For a bit of additional help to get started, please take a look at this tutorial written with Mojito. It will show you how all of the above features work and should give a good example on how to start with your app.

Go-Mojito - Code your next Go web project with (a) Mojito!

Go-Mojito is a fully customizable and modular web framework that allows you to write projects that do not hard-depend on any router, template engine, cache or logger.

Code your next Go web project with (a) Mojito!

TL;DR We turned a great concept design, created by D7mtg, into reality. The App Store listing is linked at the end of the article.

It was September 18th, 2020. The pandemic has forced many to stay at home, including myself. Just two days earlier, Apple released iOS 14 which brought us a new form of widgets that can be placed anywhere on our home screen. Widgets already existed before iOS 14, but they were hidden away on a separate page on the home and lock screen.

Many apps had already implemented widgets that can be placed on that widget page. Tesla was no exception and treated users to an interactive widget that can unlock the car or open the frunk. In fact, the ability to create interactive buttons was one of the advantages of the older widgets. But what made them quite unusable was the fact that you could not place those widgets on the home screen.

Story Time

I was browsing Twitter, which was full of iOS 14 news at the time. While browsing, I happened to bump into a repost of this Reddit post with a concept for a Tesla widget for the home screen. My opinion on it was pretty clear right away: I need to have this in my life immediately. It's providing all the information I want without opening the app, and is looking good while doing so!

I knew I wanted to make this, so I tracked down the creator and found that it was designed by a designer working for D7mtg, a branding agency in Brooklyn. I sent them a Telegram message, asking if they would give me permission to build an app based on their design. Thankfully they were quite excited about me bringing their idea to life. I worked closely with them to get to a result we are both satisfied with.

The original idea of the concept was expanded to support multiple widget sizes, as well as custom widget backgrounds and accounts with multiple cars. The app has also been released on Apple Silicon Macs, so you can keep an eye on your Tesla while working on your Mac.

‎TeSlate

‎TeSlate is a beautiful widget crafted for iOS 14. TeSlate communicates with your Tesla vehicle and shows you useful information on your home screen. Choose which car is displayed in the app.

App StoreMichael Teuscher

TL;DR: You can find the driver by clicking here. It is also available as an AUR package. For a tutorial on how to flash the firmware, please follow this guide's step 1. Also you will need version 1.92 of fprintd for this driver to work as the fork hasn't been updated to 1.94 yet.

Why I made my own driver

A few days ago I received a new work computer. As I use Manjaro Linux as my daily driver OS, it was important to me to choose something that will run it without any bigger issues. After doing my research, I settled on a Asus ROG Zephyrus G14 (2021). Basically everything it has to offer works fine under Linux, even the fancy LED cover is fully controllable. There is one noteworthy exception though: The fingerprint reader does not work under Linux. The particular fingerprint reader my machine has is a Goodix 521d. But this isn't an issue with this particular one: A quick search will reveal a whole list of unsupported fingerprint readers. While there are different reasons as to why they are not supported, for my reader there were multiple.

First of all its resolution is too small to properly work with the detection code used in the Linux library, libfprint,  responsible for fingerprint reading. While this can be worked around, there is a different issue regaring TLS communication with the device. The existing SSL library used in libfprint will not work with my reader and a second, different one would have to be introducted to the library. Last but not least, there is just no support from the vendor whatsoever. There is little to no documentation available on how to communicate with these readers.

Community Efforts

Since there is a substantial amount of users with unsupported readers of the same vendor, there has been a community effort to start working out on how to implement drivers for these devices. This is where I started my quest of getting a working driver for my reader.

After joining their discord server, I was presented with a long list of devices that are currently being tracked by the community. Tracked does not necessarily mean being worked on though, as there is too many readers and not enough programmers with respective devices around to do them all at the same time. However, for many readers there were working python scripts that are able to not only communicate with the device but also request an image from it. I was in luck, my reader had such a script as well. I had to tinker a bit with the script though to ultimately get a proper image off of my sensor.

Most development effort was focused on a different reader as they had made promising advancements towards a working driver. I survived whole 2 days of waiting before I decided that it was time to start development efforts myself. There was only two problems: First of all I have no clue about drivers or fingerprints and second I don't know how to program in C. But I figured its worth a shot anyway, there was not much to loose except a few hours of my life.

How I did it

As previously mentioned, a lot of development effort had been put into a different reader of the same vendor and there was a working python script available for my reader. The first thing I did was clone the fork of libfprint where the changes for the other reader had been made. I started comparing the libfprint implementation for that reader to what had been done in the python script for that reader to understand what I would need to change in order to make it work with my reader. So I created a copy of the existing reader's implementation and started to replace the static values of the old reader with the ones I found in the python script for my reader. Now, this was done fairly quickly and I went ahead and tested it. Absolutely nothing worked. Obviously, the devices are not identical and there was more to it than just copying over static values like configurations and shared keys.

I discovered that the protocol differs between the two readers in a few ways. For example, the bytes sent over to the device for PSK verification were not the same, despite them using the same protocol in python. So I had to expand the existing protocol implementation with the missing fields and voila, it failed again. There were not only fields missing, but their order was also incorrect. This meant that I had to shuffle the order of the fields to match the python script which finally allowed me to verify the PSK of the device. Yay!

The next big roadblock was getting the device to send me an image. While I definitely got a request to the device, and I definitely got something back from it, it came out as pure random data. I knew that the image data was supposed to be encrypted but every time I tried to decrypt the chunk of data I received, the TLS library would tell me that the data was not in fact valid TLS data. Again, a small difference between the other reader and mine was, that I would have to discard the first 9 bytes of my data chunk to get the valid TLS encrypted data to feed into the decryptor. And it took me far too long to realise that.

The third and last bigger roadblock was that I was not getting a clear image from the sensor. In fact, even after decryption it still looked like utter garbage. I checked everything: The image decoder which is needed to turn the image sent by the reader into an actual viewable picture, the decryption, every receiver the data went through. After many more hours I figured out that one of my configuration calls to the device were not working properly. There was something wrong in the protocol implementation that prevented my request from being encoded into bytes successfully and the reader never got the configuration I wanted it to have in the first place. Once I resolved this, I was able to get pictures from my reader in libfprint which meant I was technically able to enroll and verify fingers.

But there is more. Since the fingerprint reader is so small, libfprint's way of verifying fingerprints just cannot find enough details to compare against and simply fails the verification everytime, even if the finger wasn't moved since the enrollment. To counter this, instead of taking one shot of the finger, I made the program take 10 shots and stitch them together. Thats also how the swipe-style fingerprint readers work! After providing libfprint with a far bigger picture and therefore far mor details, I was finally able to enroll and verify fingerprints. Now, this method might not be the safest and there will definitely be work done for a better one. So I wouldn't recommend relying this for top secrecy, although when enrolled properly I only managed to get a false positive once with one of my other fingers.

Conclusion

I never took on this project because I had particular knowledge in fingerprint scanning, drivers or even C itself. This was sort of a fun coding challenge to myself, trying out something new I had never done before and no clue about. I definitely enjoyed the 2 days journey of writing this driver and experimenting with it. It was painful sometimes and many stupid mistakes, but getting to the stage where you can unlock your machine with a driver you (mostly) wrote is very rewarding. If you got a Goodix reader that isn't working, join the discord and check out what work has been done for your device. And if you got some spare time on your hand, you might just try to fix it yourself.

First of all, don't worry, you won't need a mod to play Quake. The custom models are contained in the resource pack you are loading from the server as you join. If you decline the resource pack, you can still play but most guns will be shown as a charged crossbow.

Custom weapon models

Quake always relied on existing items that looked somewhat like the object we wanted to make. This is where Blockbench came in. Using Blockbench, we designed and created custom item models for each of the currently available weapons.

The Railgun

The original weapon of the game, the wooden hoe, has been replaced with this custom railgun design. This type of gun will be in the center of your screen, as if you were aiming trough the non-existing scope on the weapon. We might add one later.

The Knife

Leaned on the design of the Railgun, the knife got a short, blue blade. The knife is short on purpose since its a short-range weapon. You go up to someone to use it. When you use this item, you will hold it like a sword (it is a sword) but a bit more serial-killer like.

The Rocket Launcher

The Rocket Launcher got a simple container for the rocket, with the actual rocket peaking out of the front. Since your character is carrying it on it's shoulder, you will see it on the side of your screen. Sorry to disappoint: No the rocket does not actually launch. All the gun particles have remained the same. We might change that in a future update.

The new game mechanic

You see, firing a rocket generates a lot of thrust. That thrust usually pushes you back in order to push the rocket forwards. Yes, we have added rocket recoil to the game and yes you can use it to rocket jump! Reach new heights and surprise your enemies with unexpected moves or approach vectors. It also makes for great trickshots!

Conclusion

The new models and the rocket recoil make a great addition to the game. It opens up a lot of new ways to play the game and it's just a lot of fun to play with the rocket launcher jumps. I highly recommend using the resource pack provided by the server to enjoy the new models as well.

If you found this article, you probably lost your Longhorn metadata in one or the other way. This sounds scarier than it really is, because Longhorns metadata is actually really easy to re-create manually.

Warning: While this has worked for all my volumes in the past and I have not encountered any lasting effects or data-loss, I do not guarantee your success with this method. Please make appropriate backups of the files you are editing before trying this. This is a last-resort when you have no working replicas available and cannot attach the volume at all.

Diagnosing failed metadata

The most common symptom of failed metadata is a attach-detach loop of the volume. You can see this in the Longhorn UI by filtering for the status "In Progress"

Restoring volume metadata

Once you have found a problematic volume, click on the volume to open its more detailed page. Hover over the storage path of the replica and note yourself the full storage path shown in the tool-tip as well as the volume size. See the selected text in the picture for guidance on where to hover the mouse cursor. The replica below is not affected by metadata corruption and is only used for visual reference.

For the next step you will need a remote console session to the server on which the replica is stored on. Navigate to the full storage path you noted down in the previous step. If you have one or more of the following files you are in the right place:

• volume-head-###.img
• volume-head-###.img.meta
• volume-snap-*.img
• volume-snap-*.img.meta
• volume.meta

Check the filesize of the .meta files. If one of them is 0, this is the one you need to repair. Below are guides for each kind of metadata file, as they are different!

Repairing volume.meta

You lost the main metadata file for this volume, luckily this is fixable. First, you will need an example of a valid metadata file. I will provide you with one of mine:

{"Size":8589934592,"Head":"volume-head-001.img","Dirty":true,"Rebuilding":false,"Error":"","Parent":"volume-snap-51131b80-b84f-4a33-abaf-7f8ea1a4468e.img","SectorSize":512,"BackingFilePath":""}

First you will need to calculate the correct size of your volume. This can be done by multiplying SizeInGiB x 1073741824. My volume above is 8GiB. Replace the size in the metadata with the calculated size.

Next, find your volume-head-###.img and set it as the value for the Head field. For Parent, order your volume-snap-*.img by their timestamp and choose the latest one. Once you are done the file should look somewhat like this (those below are still fake-values!):

{"Size":YourVolumeSize,"Head":"volume-head-###.img","Dirty":true,"Rebuilding":false,"Error":"","Parent":"volume-snap-*.img","SectorSize":512,"BackingFilePath":""}

Once you saved the file, Longhorn should be able to attach the volume and begin to create new replicas for it.

Repairing volume-head-###.img.meta

This one is very similar to the volume.meta file, minus some of the status fields. Here is what a valid file would look like:

{"Name":"volume-head-001.img","Parent":"volume-snap-51131b80-b84f-4a33-abaf-7f8ea1a4468e.img","Removed":false,"UserCreated":false,"Created":"2021-07-25T23:44:51Z","Labels":null}

Find your volume-head-###.img and set it as the value for the Name field. For Parent, order your volume-snap-*.img by their timestamp and choose the latest one. Once you are done the file should look somewhat like this (those below are still fake-values!):

{"Name":"volume-head-###.img","Parent":"volume-snap-*.img","Removed":false,"UserCreated":false,"Created":"2021-07-25T23:44:51Z","Labels":null}

Once you saved the file, Longhorn should be able to attach the volume and begin to create new replicas for it.

Repairing volume-snap*.img.meta

This one is almost equal to the volume-head-###.img.meta file. Here is what a valid file would look like:

{"Name":"volume-snap-51131b80-b84f-4a33-abaf-7f8ea1a4468e.img","Parent":"","Removed":true,"UserCreated":false,"Created":"2021-07-25T23:44:51Z","Labels":null}

Remove the .meta from the filename and set it as the value for the Name field. For Parent, order your volume-snap-*.img by their timestamp and choose the one older than the snap you are currently fixing. If there is no older one, leave it empty. Once you are done the file should look somewhat like this (those below are still fake-values!):

{"Name":"volume-snap-*.img","Parent":"volume-snap-*.img OR empty","Removed":true,"UserCreated":false,"Created":"2021-07-25T23:44:51Z","Labels":null}

Once you saved the file, Longhorn should be able to attach the volume and begin to create new replicas for it.

I hope you were able to restore your metadata with this guide.

We are proud to announce the public testing phase of the Quake mini-game. Our Team has worked very tirelessly to optimize performance, add more weapons and to create a whole new map.

New Map

If you have played CS:GO you will probably recognize this one! Recreated in Minecraft, by 0SkillAllLuck, we are happy to bring you Dust 2 as a playable Quake map. Unlike CS:GO, you can visit the roof of the buildings thanks to the Jump Boost! But fear not, camping doesn't get you very far in this game (anymore).

New Weapons

While we kept the traditional Railgun, we have added two additional weapons to your inventory.

The Rocket Launcher
This is the first weapon to not only deal direct-impact damage but also explosion damage to anyone close during impact. That's right: You can now die slowly. This weapon has a cooldown of 2 seconds and deals explosion damage to players in a 5 block range. If you are hit directly by the rocket, you will die immediately. Rockets fly slower than the railgun projectile and they can only directly kill one person.

The Knife
This weapon does not fire a projectile (Sorry). Instead you can slice up that annoying camper that just never moves (Works best if you strike behind their back). You do need two hits to kill a player, else you could do a hit-and-run on nearby players. Apart from that, this item is supposed to be a bit harder to use.

Optimizations

This section is a bit more technical. If you don't care about that, skip to the next section :)

The entire GameAPI and Game have been rewritten to eliminate duplicate code and reduce the amount of event handling. We have also removed all the NMS (Net-Minecraft-Server) code and instead rely on the integrated, version-independent API's.

Another big change is that all weapons are now handled asynchronously from the main thread. This 100% prevents the possibility of a weapon lagging out the server. Weapons cannot affect each other either. This was necessary to create the rocket launcher with it's slower projectile speed.

How to test the game

The game mode is publicly available on mc.infinytum.co. You will need at least one other player to play the game. You can share this address with whoever you like. You will also need Minecraft Java Edition 1.17.1 to play. The public testing server might restart from time to time to install the latest updates as we continue development on the game.

Fair warning though: The game might or might not have anything to do with the original Quake.

If you find any bugs or have other questions about the game, you can message team@infinytum.co

If you have played any kind of competitive online game, you have surely encountered at least one of these things: The server appears to be lagging, or is it just your connection, or maybe the enemies connection?

While we won't talk about the delicate voice chat debate that follows, it's needless to say that this is an issue that needs to be addressed in a multiplayer shooter. Even if it's a Minecraft shooter. Of course, we can't magically fix someone's internet connection or stop a server from lagging once in a lifetime. But what we can do is being transparent about all those things.

TPS: What is it and why does it matter

In the world of Minecraft, a servers performance can be measured in so-called Ticks Per Second (TPS). Idealy, there are 20 ticks in one second. That means, that the server has completed all checks and tasks 20 times per second. Those tasks vary from mob/player movement to custom plugin code (like Quake).

Now what happens if the server cannot complete 20 ticks in a second? Well, you as a player will perceive this as lag. You might teleport back to a location you just walked away from because the server simply didn't have time to process your previous movement and thinks that you are moving to fast (hacking). You will also notice choppy movement of other players and your weapons might not work as expected. This kind of lag affects all players and its entirely a server problem.

We are doing our best to keep our code outside of those ticks, to add as little load as possible to the server. But we also have to worry about what happens if the server does lag. This is why we added a feature to all games built with our GameAPI.

Server TPS

The Server's TPS will always be visible at the bottom of the TabList (Minecraft Java Edition). To make it a little more useful, we also added the current game state. The TPS will change color based on our rating of the TPS.

Green: OK, TPS is acceptable for playing.
Yellow: Light to moderate lag may occurr.
Red: Unplayable, too much lag to play the game.

You can also show the current server TPS by typing '/ticks' in the chat. It is usually a bit more precise than necessary and is rarely the full 20 TPS.

Bad Ping: It doesn't only affect you

The most obvious issue of a bad connection is usually your playing experience. Everything seems to be slow, your shots are not going as fast as you'd like them to go and you seemingly hit someone but they didn't die. But you are also lagging for everyone else on the server. Your movement might be choppy, making it harder (or easier) for people to aim at you.

We are trying to have a good connection to everyone by putting our servers into a well-connected datacenter. This may help, but it will not fix the problem of simply bad internet connections at home. Once again, being transparent can help to at least calm fellow players on the server and to prevent claims of server lag.

Ping Transparency

Every player has their ping next to their name in the TabBar. This feature also works with Bedrock clients! This way, everyone knows who they are playing with and what kind of issues they can expect with the other players.

Your own ping can also be shown in chat by typing '/ping' in the chat. It should print the exact same number as in the TabList but this time the number is colored depending on it's rating.

Green: Great, you should not have any issues playing
Yellow: OK, most likely you won't notice any issues but there might be slight delay.
Red: Noticeable lag, you can still play
Dark Red: Really Lagging, we'd not recommend playing like this.

Infinytum will be carrying out maintenance on all systems (Networking, Storage, Compute) over the span of 3 days. To prevent noticeable downtime for users, the event takes place during the night (CEST!).

We will be migrating controller servers to new disks to increase their reliability and speed to take on more requests. The network plane has to be restarted completely in order to propagate a cluster-domain change. Because the network plane has to shutdown completely, workload servers have to shutdown all their scheduled workloads to prevent issues with network attached disks. During this restart services will become unresponsive and unreachable until the network plane and workload server have restarted. All workloads will automatically restore their functionality and services will be reachable again.

All Infinytum services including but not limited to:

• Docker Registry
• GitLab
• Drone CI
• Minecraft Ingress
• Web Ingress

will be unreachable as well during the downtime.

Once again it's time for another TeSlate update. Over the past months we have received lots of feedback to our app and one particular feature has been requested by many of you.

A Customizable Widget Background

There are many reasons to change your background to something different than your vehicle color: Some users prefer their UI in a darker color, some simply don't enjoy having the same color in front and back and some want to replicate the TeSlate logo color scheme ;)

Of course once you changed the color manually, you can always switch back to the automatic coloring of the widget. The color selection will be applied to all widgets, no matter their size.

If you haven't received the update already, either wait for the iPhone to do it automatically or manually update TeSlate in the AppStore.

‎TeSlate

‎TeSlate is a beautiful widget crafted for iOS 14. TeSlate communicates with your Tesla vehicle and shows you useful information on your home screen. Choose which car is displayed in the app.

App StoreMichael Teuscher